| ||||||||||||||||
A new Firefox 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/ (Log in to post comments)
A new Firefox buffer overflow Posted Sep 9, 2005 15:18 UTC (Fri) by gjvo (guest, #951) [Link] I am sorry, but I cannot convince firefox or mozilla to crash on that URL (nor on longer ones).
A new Firefox buffer overflow Posted Sep 9, 2005 15:34 UTC (Fri) by tjw.org (guest, #20716) [Link] I am sorry, but I cannot convince firefox or mozilla to crash on that URL (nor on longer ones).I believe it is the parsing of this link out of HTML that causes the crash, not visiting such a link. If you click on this link, firefox (1.0.6 and 1.5b1) will crash. That file contains only the text: <A HREF=https:--------------------------------------------- >
A new Firefox buffer overflow Posted Sep 9, 2005 15:38 UTC (Fri) by oseemann (subscriber, #6687) [Link] My 1.5 beta 1 does not crash on that link, and the body contains only <A HREF=https: >
A new Firefox buffer overflow Posted Sep 9, 2005 15:39 UTC (Fri) by oseemann (subscriber, #6687) [Link] However, it crashed while posting the parent comment, hehe.
A new Firefox buffer overflow Posted Sep 9, 2005 17:43 UTC (Fri) by sbergman27 (guest, #10767) [Link] My Firefox 1.0.6 on Fedora Core 4 does not crash when loading the link. And it really does contain the dashes if you save it with wget. However, if you load it into FF and then use "View->Page Source" you don't see the dashes.I'm also pretty confident that it will not crash when posting this comment after loading the previous link. Stand by...
A new Firefox buffer overflow Posted Sep 9, 2005 17:45 UTC (Fri) by sbergman27 (guest, #10767) [Link] Nope, no crash. Mr. Full-Disclosure would seem to be slightly trigger-happy.
A new Firefox buffer overflow Posted Sep 9, 2005 16:28 UTC (Fri) by lurk546 (subscriber, #17438) [Link] I'm running 1.0.6. I downloaded the link and the downloaded file will cause mozilla to crash. You're correct about the file. It doesn't contain the dashes
A new Firefox buffer overflow Posted Sep 9, 2005 16:29 UTC (Fri) by lurk546 (subscriber, #17438) [Link] I should have said mozilla firefox, not mozilla.
A new Firefox buffer overflow Posted Sep 9, 2005 16:32 UTC (Fri) by lurk546 (subscriber, #17438) [Link] Mozilla (seamonkey) handles the offending file just fine.
A new Firefox buffer overflow Posted Sep 9, 2005 19:33 UTC (Fri) by NightMonkey (subscriber, #23051) [Link] This caused my Mozilla 1.7.11 (Navigator) to freeze, requireing a SIGTERM.
A new Firefox buffer overflow Posted Sep 10, 2005 22:45 UTC (Sat) by hconnellan (subscriber, #231) [Link] Same here with firefox - 1.0.6 from ubuntu
A new Firefox buffer overflow Posted Sep 9, 2005 15:35 UTC (Fri) by tjw.org (guest, #20716) [Link] Vendor Status: Mozilla was notified, and im guessing they are working on a patch. Who knows though?Heh. I have the feeling this guy has some sort of gripe with mozilla. On the other hand, he could just be a jerk.
A new Firefox buffer overflow Posted Sep 9, 2005 16:38 UTC (Fri) by ajross (subscriber, #4563) [Link] Clearly both. Endangering third party users because you're piffed at the development team is just plain antisocial. This moron should be shunned.
A new Firefox bufferoverflow Posted Sep 9, 2005 17:09 UTC (Fri) by Duncan (guest, #6647) [Link] Well... I don't know... We don't know (at least from this) how long itwas between notification and public release. If he notified them and a few hours later released the details publicly, then yeah, more time would have been nice. Even then, tho, he's under no obligation, really, and public release is certainly better than offering it to some trojan writer for a bounty of some sort. We've certainly criticized MS for taking forever to release updates. A few days notice certainly would have been nice, but as I said, there's no obligation, and we don't /know/ how long the private notice was, so we shouldn't just go condemning him out of hand. It's the same point Linus made awhile ago when someone brought up a security issue there. Yeah, more notice would have been nice, but at least he released it publicly instead of selling out to some malware writer or exploiting it himself. Thus, he's still a good guy, and shouldn't be attacked as if he's not. Duncan
A new Firefox bufferoverflow Posted Sep 9, 2005 17:17 UTC (Fri) by zeekec (subscriber, #2414) [Link] According to this he gave them 5 days.
A new Firefox bufferoverflow Posted Sep 9, 2005 17:19 UTC (Fri) by zeekec (subscriber, #2414) [Link] Actually, acording to the text of the message, he gave them 4 days.
A new Firefox buffer overflow Posted Sep 9, 2005 18:36 UTC (Fri) by job (guest, #670) [Link] The only one who endangered anybody was the one put the bug there in the first place, and they obviously didn't do it on purpose. It's easy to flame people over the Internet but this particular person actually contributed something by identifying a critical bug. What have you done for the world today, that gives you the right to flame others?
Full disclosure works. We've seen it before and we'll see it again. The time frame here was not unusual, the finder has the right to claim credit for the work he's done. This stuff is much harder to find than to fix.
A new Firefox buffer overflow Posted Sep 9, 2005 19:26 UTC (Fri) by dvrabel (subscriber, #9500) [Link] I don't think anyone is endangered by a browser bug.
A new Firefox buffer overflow Posted Sep 9, 2005 19:31 UTC (Fri) by NightMonkey (subscriber, #23051) [Link] Guess you don't use electronic banking online? Or credit cards? Or send passwords over the web? Maybe not life-endangering, but certainly credit-endangering ;).
A new Firefox buffer overflow Posted Sep 9, 2005 17:36 UTC (Fri) by dark (subscriber, #8483) [Link] It could also be that he doesn't trust it to stay secret. Perhaps it leaked during discovery ("Hey guys, this function looks a little odd") or confirmation ("Can you test this page with your browser?"), or maybe he even got it from someone else and doesn't want to compromise his sources.
A new Firefox buffer overflow Posted Sep 9, 2005 19:28 UTC (Fri) by NightMonkey (subscriber, #23051) [Link] Hey, if he can find it, someone else can find it (and might already have). That's one reason why full disclosure is the best disclosure. The other way is to log in and find all your JPEG files changed to images of Don Rickles, and not be forewarned because the Good Guys were too bogged down in paperwork and stonewalling.
Even if you believe that FD is "endangering users", well, the users COULD just not use the affected application until a fix is available and use another browser. But, no, that's asking too much. ;)
A new Firefox buffer overflow Posted Sep 10, 2005 6:04 UTC (Sat) by lacostej (guest, #2760) [Link] "Hey, if he can find it, someone else can find it (and might already have). That's one reason why full disclosure is the best disclosure."
Except that you go from, "maybe a couple of guys knew how to use it", to now "every script kiddie is a potential (ab)user of the flaw".
I for one would accept a couple of weeks notice and let them the time to fix it. At least if it's not something that can spread automatically.
not really... Posted Sep 11, 2005 19:44 UTC (Sun) by dark (subscriber, #8483) [Link] He didn't provide a script. By definition, script kiddies can't use it unless there's a script :)
Personally, I'd much rather use a different browser for a couple of weeks while they fix it, instead of being unaware of the danger. And experience shows that after disclosure, it won't take weeks to fix.
A new Firefox buffer overflow Posted Sep 9, 2005 18:14 UTC (Fri) by thompsot (guest, #12368) [Link] Workaround found at this link works: http://www.mozillazine.org/talkback.html?article=7307#3 I'm using FF 1.0.6 on Debian and it was crashing regularly before, but not after I disabled IDN. Temporary fix...
C style code in C++ Posted Sep 9, 2005 19:21 UTC (Fri) by NAR (subscriber, #1313) [Link] I've taken a look at the mentioned function in the mozilla CVS and found that they use char* and memcpy for string operations instead of std::string. Why? (BTW the perl code in the Mozilla cross-reference site emits warings into the generated HTML code - not a good PR :-( )
C style code in C++ Posted Sep 9, 2005 20:22 UTC (Fri) by ronaldcole (guest, #1462) [Link] Why? Because after two decades, people still treat C++ as "Super-duper C".
C style code in C++ Posted Sep 9, 2005 21:11 UTC (Fri) by djrom (guest, #26074) [Link] I have another guess. If you have a look at the Mozilla's C++ portability guide, you'll see that they advise not to use many C++ "over-cool" features because they are not *that* portable. Maybe they wanted to avoid using stl for the same reason. But that's just a guess.
C style code in C++ Posted Sep 9, 2005 21:56 UTC (Fri) by lordsutch (guest, #53) [Link] Indeed:Don't use C++ standard library features, including iostream
C style code in C++ Posted Sep 9, 2005 23:03 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] That's just broken. The C++ standard has been official for 7 years now, and the problems described in your quote are largely a thing of the past.But even before that, it was not hard to write portability layers to hide such problems, and opportunities for buffer overflows, leaks, and heap corruption are greatly reduced if standard STL classes (such as std::vector) are used instead of fixed-length buffers or arrays allocated by malloc or new. Using C++ and standard classes gives you fewer buffer overflows than you'll get with C; using C++ without standard classes will give you more ways to shoot yourself in the foot, and more crashes and security holes.
C style code in C++ Posted Sep 10, 2005 14:35 UTC (Sat) by khim (subscriber, #9252) [Link] The C++ standard has been official for 7 years now And... ? What does this mean exactly. We still are using test with question "How many ANSI C++ compatible compilers can you name ?". Evaluation: minus five points per named compiler. Situation with C++ is total mess: C++ standard is official for 7 years now but there are no ANSI C++ compatible compilers. Not even single one. Some are just plain broken (do not support namespaces or something), some will crash on template-heavy code, some have incompatible STL, etc.
C style code in C++ Posted Sep 10, 2005 20:50 UTC (Sat) by nix (subscriber, #2304) [Link] If you ignore `export' (not a brilliant move on the committee's part IMHO), a significant number of compilers are close to standards-compliance: close enough that a *lot* of other software uses the STL and friends without trouble, and has for years.
C style code in C++ Posted Sep 12, 2005 9:38 UTC (Mon) by ajf (subscriber, #10844) [Link] That's just broken. The C++ standard has been official for 7 years now, and the problems described in your quote are largely a thing of the past. Well, the document quoted has been on mozilla.org since the project was released (so it may well be based on an internal Netscape document that's even older). Hey, that's 7 years ago too! They probably could update it to take advantage of improvements in compilers since then. All they would need to do is divert time and resources away from developing Mozilla — you know, the reason they exist, that's all — to test compatibility with all the compilers they still care to support. Can you be so smugly sure that it would be worth it?
C style code in C++ Posted Sep 9, 2005 21:13 UTC (Fri) by mtaht (✭ supporter ✭, #11087) [Link] That's because, for nearly two decades, the c++ stl wasn't stable or portable enough to use.
A new Firefox buffer overflow Posted Sep 10, 2005 1:21 UTC (Sat) by rm6990 (guest, #30921) [Link] Red Hat took this one pretty seriously.
http://rhn.redhat.com/errata/RHSA-2005-768.html
Normally, Red Hat waits for a patch from Mozilla, then tests it for a few days, then releases their own update. This update was released today by Red Hat, independant of Mozilla's own update.
This is a good thing though, as Red Hat's fixes will most likely be used by the Mozilla Foundation.
A new Firefox buffer overflow Posted Sep 11, 2005 3:53 UTC (Sun) by bojan (subscriber, #14302) [Link] Fedora patched FF and Mozilla too.
Thunderbird Posted Sep 10, 2005 7:49 UTC (Sat) by donio (subscriber, #94) [Link] Is Thunderbird vulnerable? Wouldn't an HTML email containing the link trigger the vulnerability? I haven't seen this mentioned in any of the disclosures.
|
||||||||||||||||