[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri Sep 9 13:48:47 2005
From: dave at immunitysec.com (Dave Aitel)
Subject: Mozilla Firefox "Host:" Buffer Overflow
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@...fdavis.com
>
>-----Original Message-----
>From: full-disclosure-bounces@...ts.grok.org.uk
>[mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Tom Ferris
>Sent: Friday, September 09, 2005 2:10 AM
>To: full-disclosure@...ts.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/
>
>
Powered by blists - more mailing lists