Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users
Status: Fixed
Last visit 22 days ago
Closed: Apr 2015
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: ----
Type: Bug-Security

Sign in to add a comment
Security: spell checking dictionaries are fetched over HTTP, and large responses lead to a crash
Reported by, Apr 21 2015 Back to list

This bug is very similar (but different) to another that was worked recently,

This time the insecure URL is used when downloading spell checking dictionaries.

The code that needs to be updated to use HTTPS is:

An example insecure URL that is used is:

The problem is that the insecure requests can be tampered with by an active network attacker to respond with a large response body which causes the Chrome process to allocate large amounts of memory and/or crash with SIGABRT.

Here is an example of what happens on the command line when subject to an active network attack:
> google-chrome --incognito
[5989:5989:0421/] Invalid url pattern: chrome://print/*
[5989:5989:0421/] Invalid URL: '' for extension gmlllbghnfkpflemihljekbapjopfjik
tcmalloc: large alloc 1073741824 bytes == 0x3cf8eed0000 @ 
[5989:6024:0421/] Out of memory.
Aborted (core dumped)

Chrome Version: 42.0.2311.90 stable
Operating System: Ubuntu 14.04.2 LTS

1) simulate needing to download a new language by removing existing dictionaries: rm -rf ~/.config/google-chrome/Dictionaries
2) perform an active network attack that makes the request to respond with a 1GB response (I generated a test file with: dd if=/dev/zero of=gig bs=1M count=1024).
3) now cause the browser to attempt to download the language. there are a few ways of achieving this. the most generic that i found was to:
  a) navigate to
  b) right click the mouse in the main search entry text box. doing so notices that the language needs to be downloaded and causes a crash. my intuition says that this occurs because of a need to populate the spelling portion of the context menu, although i did not verify that.

Type of crash: entire browser sig abort
Crash State: see screen shot and description above
146 KB View Download
Comment 1 by, Apr 21 2015
As far as you can tell, is the dictionary checked in any other way (eg hash verification), or could the attacker also provide you with incorrect spelling suggestions?
There are some sanity checks on structure of the dictionary. But, I did not see any cryptographic signature checks. So, given a little playing around learning that file format, it may be possible to suggest incorrect spellings. These are the areas of the code that makes me think it's possible:
I was able to inject the Afrikaans (af-ZA-3-0.bdic) dictionary in place of the US English one (en-US-4-0.bdic) and cause my spelling suggestions to be totally off.
I could probably create my own dictionary also as the only check looks like a md5sum of the a big part of the bdic file. But, that's not a signature which would require a signing key, just a md5 to verify the integrity of the file. So, yes, an injected response can change the suggestions.
Labels: Security_Severity-Low Security_Impact-Stable Cr-UI-Browser-Spellcheck
Status: Assigned
Adding OWNERS for spellchecker. Could one of you please take a look at this?
Comment 5 by, Apr 21 2015
Comment 6 by, Apr 21 2015
I thought we had an MD5 signature check... Ah, yes:

felt@: Yes, I'm aware of the security shortcomings around that MD5 check. Can we do a sec-audit of this whole area at some point?

The MD5 would only assure integrity (of part of the bdic file), not authenticity. Basically, it only assures that what is sent/injected is what is received. The quick fix to get authenticity is to change the scheme to HTTPS in the URL at
Doing that would prevent being able to inject a tampered response to either crash the browser or alter the spelling suggestions.
Comment 8 by, Apr 22 2015
Sorry, misread your comment to imply there's no integrity check. Lack of coffee. As said above, I'm aware of the security issues only checking integrity.

While https sounds simple, it's not that easy in actuality. Currently pinging top people to find out how we can get there. TOP. PEOPLE ;) (

Comment 9 by, Apr 23 2015
Status: Started
Project Member Comment 10 by, Apr 25 2015
The following revision refers to this bug:

commit 6703b5a51cedaa0ead73047d969f8c04362f51f1
Author: groby <>
Date: Sat Apr 25 02:46:16 2015

[Spellcheck] Switch to https download

Download dictionaries via https instead of http, preventing MITM
attacks against dicts. Plus, HTTPS 4 LYFE!

BUG= 479162 

Review URL:

Cr-Commit-Position: refs/heads/master@{#326954}


Comment 11 by, Apr 25 2015
Status: Fixed
Top people have replied with top solutions. We should be done. 
Project Member Comment 12 by, Apr 25 2015
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Top o' the mornin' to ya :)
Thanks for making the quick update. Do you think this will be eligible for a bounty for the report and/or location of the probable fix?
Comment 14 by, Apr 27 2015
Labels: reward-topanel
Hey Mike - we'll take a look at this in our next panel round, though a reward is unlikely based purely on the low severity. Nevertheless, we'll take a look.
Labels: Release-0-M44
Labels: -reward-topanel reward-500 reward-unpaid
Congratulations - $500 for this report!

Reward Panel notes: "attack surface of malformed dictonary files is significant enough for a reward".

The payments team will be in contact within two weeks and I'll update this bug with a CVE later on this evening, though keep in mind that this won't be made public until after M44.

*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an established charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
Thanks for the reward and for the feedback on why it qualified. That helps guide direction of further research.
Hi, I haven't heard from payments on this one yet.
Yikes - thanks for the reminder. I'll chase this.
Labels: -reward-unpaid reward-inprocess
Hi, just checking on this because I haven't seen the CVE assigned or the reward come through yet.
Labels: -reward-inprocess
Processing via our e-payment system can take up to two weeks, but the reward should be on its way to you. Thanks again for your help!

(Note: sorry for the delay here - it turns out in the new payment system, these payments were waiting for a second approval from me).
@mbarbella - can you please help Mike out with a CVE?
Labels: CVE-2015-1288
Assigning CVE-2015-1288 to this bug.
Project Member Comment 26 by, Aug 1 2015
Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Project Member Comment 27 by, Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Project Member Comment 28 by, Oct 2 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: allpublic
Components: -UI>Browser>Spellcheck UI>Browser>Language>Spellcheck
Sign in to add a comment