Message-ID: <c83481820905271920i1c2262d3y3fe7c5e5915a51f7@mail.gmail.com>
Date: Wed, 27 May 2009 22:20:11 -0400
From: Jeremy Brown <0xjbrown41@...il.com>
To: Thierry Zoller <Thierry@...ler.lu>, bugtraq@...urityfocus.com, 
	full-disclosure@...ts.grok.org.uk
Subject: Re: [TZO-27-2009] Firefox Denial of Service
	(Keygen)

Looks like somebody's been using a browser fuzzer :)

On Wed, May 27, 2009 at 9:14 PM, Thierry Zoller <Thierry@...ler.lu> wrote:
> ________________________________________________________________________
>
>              From the very-low-hanging-fruit-department
>                   Firefox Denial of Service (KEYGEN)
> ________________________________________________________________________
>
>
> Release mode: Forced release.
> Ref         : [TZO-27-2009] - Firefox Denial of Service (KEYGEN)
> WWW         : http://blog.zoller.lu/2009/04/advisory-firefox-denial-of-service.html
> 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)
> - Likely : All Firefox versions supporting 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 submitting 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. Restarting the
> Firefox process and restoring the previous Firefox session will
> re-spawn the tab and start the loop again.
>
> 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
> memory leaks that directly or indirectly happen during key generation
> need to be investigated thoroughly.
>
>
> IV. Proof of concept (hold your breath)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> <html>
> <body onLoad="document.forms[0].submit()">
> <FORM>
> <KEYGEN NAME="somekey" CHALLENGE="1125983021">
> <INPUT TYPE="submit" NAME="SubmitButton" VALUE="Done">
> </FORM>
> </html>
>
> Live : http://secdev.zoller.lu/ff_dos_keygen.html
>
>
> 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 repeatedly occurred during testing the POC
>
> 24/12/2008 : dveditz@...illa.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
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists