Advisory : Firefox Denial of Service (KEYGEN)

Comment:

I have received interesting and mixed feedback from posting the above "bug".

• First I'd like to clarify that a vulnerability is measured by the impact it causes, not how easy it is to find it and not by how technically challenging a vulnerability is.
  
  
• Secondly, vendors appear to not like it but remotely controlling the availability of an application is a security issue. It is the A in the CIA concept. If you are interested in that discussion I wrote a small blog rant about the "Denial of service is not a security issue" mindset of certain vendors.
  
  
• Is this bug a vulnerability? - yes. Is is critical ? Clearly no. Stop seeing the world in Black or White. Something can be a vulnerability and still not be critical for the general public. However make no mistake, some bugs that are (for example) rated medium can become critical for certain companies that use the products in certain ways or critical parts of an infrastructure rely on that particular application.
  
  
• This is the reason I give no risk rating, what for ? I can't assess the risk an customer runs in specific environments when this vulnerability hits the product, I have no way to assess the risk whatsoever. I think it is highly misleading to have a vendor rate risk for a vulnerability. What I give is a description of the impact, with an description of the impact the customer of that product is actually able to assesses the risk, he is the only one that can.
  
  
• To illustrate this point take the bug above and think about several scenarios where this bug might actually pose a problem. Have one ? Fine. I have one too; what about for example Internet Kiosk vendors ? i.e the terminals at airports or cities that give access to the internet. Browse to the PoC and the terminal can no longer be used - so, for terminals offering pay for access service, this might mean actually income loss. (I am aware that some "restart" the whole OS or the envrionment periodicaly to clean up the mess left behind) Still I think you'll get the point here, there are a lot more scenarios like this.
  
  There is more then the typical End-user at home sitting before his pc that kills the process and restarts firefox.
  
  
• During my years doing security consultancy, one of the most astonishing things I learned is the immense variety of how applications are used by different companies. There is no way to summarise risk.
  

---

Release mode : Forced release

Ref : [TZO-27-2009] - Firefox Denial of Service (KEYGEN)

Vendor : http://www.firefox.com

Status : No patch

CVE : none provided

Credit : none

Bugzilla entry: https://bugzilla.mozilla.org/show_bug.cgi?id=469565

Security notification reaction rating : There wasn't any appropriate reaction.

Notification to patch window : x+n

Disclosure Policy : http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html


Affected products :
- Firefox 3.0.10 (Windows)
- probably all versions that support the keygen tag.

I. Background

Firefox is a popular internet browser from the Mozilla Corporation. In 2007 the Mozilla Corporation had a revenue of over 75 million dollars [1], out of which 68 million where made with a search advertising deal, in other words with the search box in Firefox that defaults to Google.

I envy the spirit of everyone that works on Firefox code in their spare time,for free.

II. Description

This bug is a simple design bug that results in an endless loop (and interesting memory leaks). Once upon a time Netscape thought it would be a great idea to add the keygen tag (KEYGEN) as a feature to their Browser. The keygen tag offers a simple way of automatically generating key material using various algorithms. For instance it is possible to generate RSA, DSA and EC key material.

"The public key and challenge string are DER encoded as PublicKeyAndChallenge and then digitally signed with the private key to produce a SignedPublicKeyAndChallenge. The SignedPublicKeyAndChallenge is base64 encoded, and the ASCII data is finally submitted to the server as the value of a name-value pair, where the name is specified by the NAME attribute of the KEYGEN tag."

More information: https://developer.mozilla.org/En/HTML/HTML_Extensions/KEYGEN_Tag

This feature includes the automatic submission of the public part to a script, the crux. The Keygen tag reloads the document by submiting the public key as an argument to the current URI. Combining this with a javascript body onload() call (or meta refresh) results in an neat endless loop blocking access to the UI.

Furthermore memory is leaked during the process.

III. Impact

The browser doesn't respond any longer to any user input, tabs are no longer accessible, your work if any might be lost. According to a Bugzilla entry memory is also leaked during the process.

So let's recap, we have a function that generates key material and looping causes memory to leak. One might think this should be important enough to investigate, especially if you know that for DSA for instance, only a few bits of k can reveal an entire private key. [3]

Note: I am not saying the memory leaks include key material, seeing the lack of interest this bugzilla ticket triggered, I have not considered investigating further. What I am saying is that if security is taken seriously such bugs need to be investigated thoroughly.

IV. Proof of concept

Link to POC


IV. Disclosure timeline

DD/MM/YYYY

• 14/12/2008 : Created bugzilla entry (security) with (the wrong) proof of concept file.
  
  
• 14/12/2008 : Attached the correct POC file (mea culpa) and a stack trace and details of memory corruption that repeatitly occured during testing the POC
  
  
• 24/12/2008 : dveditz@mozilla.com comments : "I can definitely confirm the denial of service aspect, and there's a very minor memory leak (after 9 hours of CPU time memory use went from 60MB to 360MB). Haven't been able to reproduce a crash."
  
  
• 27/05/2009 : The 4 month grace period [2] given is reached. Release of this advisory.

[1]http://www.mozilla.org/foundation/documents/mf-2007-audited-financial-statement.pdf
http://www.guidestar.org/FinDocuments//2007/200/097/2007-200097189-047bbaa9-9.pdf
[2]http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html
[3]http://rdist.root.org/?s=dsa