[Full-disclosure] Mozilla Firefox "Host:" Buffer Overflow

[Dave Aitel]

It's not consideration to hide the actual risk from users of the 
product. That's just Microsoft hogwash.

Right now, everyone knows they are at risk, and what to do about it - we 
can stop using Firefox if we think it's a high enough risk vulnerability 
to do so. This is definately better than just being in the dark for 
another week or so until they get the patch done.

-dave


Larry Seltzer wrote:

>Two interesting points: 
>
>1) It took several minutes and more browsing elsewhere (in Bugzilla) before
>my browser blew up after testing the POC.
>
>2) When you reported a "Windows XP SP2 IE 6.0 Vulnerability"
>(http://security-protocols.com/modules.php?name=News&file=article&sid=2891)
>and a "Windows XP SP2 Remote Kernel DoS"
>(http://security-protocols.com/modules.php?name=News&file=article&sid=2783)
>you left the details of the bug and the POC out. Personally, I generally
>approve of that, but why don't Mozilla users deserve as much consideration?
>
>Larry Seltzer
>eWEEK.com Security Center Editor
>http://security.eweek.com/
>http://blog.ziffdavis.com/seltzer
>Contributing Editor, PC Magazine
>larryseltzer at ziffdavis.com 
>
>-----Original Message-----
>From: full-disclosure-bounces at lists.grok.org.uk
>[mailto:full-disclosure-bounces at lists.grok.org.uk] On Behalf Of Tom Ferris
>Sent: Friday, September 09, 2005 2:10 AM
>To: full-disclosure at lists.grok.org.uk
>Subject: [Full-disclosure] Mozilla Firefox "Host:" Buffer Overflow
>
>Mozilla Firefox "Host:" Buffer Overflow
>
>Release Date:
>September 8, 2005
>
>Date Reported:
>September 4, 2005
>
>Severity:
>Critical
>
>Vendor:
>Mozilla
>
>Versions Affected:
>Firefox Win32 1.0.6 and prior
>Firefox Linux 1.0.6 and prior
>Firefox 1.5 Beta 1 (Deer Park Alpha 2)
>
>Overview:
>
>A buffer overflow vulnerability exists within Firefox version 1.0.6 and all
>other prior versions which allows for an attacker to remotely execute
>arbitrary code on an affected host.
>
>Technical Details:
>The problem seems to be when a hostname which has all dashes causes the
>NormalizeIDN call in nsStandardURL::BuildNormalizedSpec to return true, but
>is sets encHost to an empty string.  Meaning, Firefox appends 0 to approxLen
>and then appends the long string of dashes to the buffer instead.  The
>following HTML code below will reproduce this issue:
>
><A HREF=https:--------------------------------------------- >
>
>Simple, huh? ;-]
>
>Vendor Status:
>Mozilla was notified, and im guessing they are working on a patch. Who knows
>though?
>
>Discovered by:
>Tom Ferris
>
>Related Links:
>www.security-protocols.com/firefox-death.html
>www.security-protocols.com/advisory/sp-x17-advisory.txt
>www.security-protocols.com/modules.php?name=News&file=article&sid=2910
>
>Greetings:
>chico, modify, ac1djazz, dmuz, aempirei, Daniel Sergile, tupac shakur, and
>the rest of the angrypacket krew.
>
>Copyright (c) 2005 Security-Protocols.com
>
>Thanks,
>
>Tom Ferris
>Researcher
>www.security-protocols.com
>Key fingerprint = 0DFA 6275 BA05 0380 DD91  34AD C909 A338 D1AF 5D78
>_______________________________________________
>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/
>  
>