[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Full-disclosure] [TZO-27-2009] Firefox Denial of Service (Keygen)
- To: Thierry Zoller <Thierry@xxxxxxxxx>, bugtraq@xxxxxxxxxxxxxxxxx, full-disclosure@xxxxxxxxxxxxxxxxx
- Subject: Re: [Full-disclosure] [TZO-27-2009] Firefox Denial of Service (Keygen)
- From: Jeremy Brown <0xjbrown41@xxxxxxxxx>
- Date: Wed, 27 May 2009 22:20:11 -0400
Looks like somebody's been using a browser fuzzer :)
On Wed, May 27, 2009 at 9:14 PM, Thierry Zoller <Thierry@xxxxxxxxx> 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@xxxxxxxxxxx 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/