There is a serious vulnerability in Mozilla Firefox, tested with 2.0.0.1, but quite certainly affecting all recent versions. The problem lies in how Firefox handles writes to the 'location.hostname' DOM property. It is possible for a script to set it to values that would not otherwise be accepted as a hostname when parsing a regular URL - including a string containing \x00. Doing this prompts a peculiar behavior: internally, DOM string variables are not NUL-terminated, and as such, most of checks will consider 'evil.com\x00foo.example.com' to be a part of *.example.com domain. The DNS resolver, however, and much of the remaining browser code, operates on ASCIZ strings native to C/C++ instead, treating the aforementioned example as 'evil.com'. This makes it possible for evil.com to modify location.hostname as described above, and have the resulting HTTP request still sent to evil.com. Once the new page is loaded, the attacker will be able to set cookies for *.example.com; he'll be also able to alter document.domain accordingly, in order to bypass the same-origin policy for XMLHttpRequest and cross-frame / cross-window data access. A quick demonstration is available here: http://lcamtuf.dione.cc/ffhostname.html If you want to confirm a successful exploitation, check Tools -> Options -> Privacy -> Show Cookies... for coredump.cx after the test; for the demo to succeed, the browser needs to have Javascript enabled, and must accept session cookies. The impact is quite severe: malicious sites can manipulate authentication cookies for third-party webpages, and, by the virtue of bypassing same-origin policy, can possibly tamper with the way these sites are displayed or how they work. Regards, /mz http://lcamtuf.coredump.cx/ Reproducible: Didn't try https://bugzilla.mozilla.org/show_bug.cgi?id=370445 http://seclists.org/fulldisclosure/2007/Feb/0340.html
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-0981
I wasn't able to reproduce the bug, since Squid would step in and give me an "Invalid URL" error... however, I've hopefully addressed the problem with this patch: https://bugzilla.mozilla.org/attachment.cgi?id=255252 The upstream development team have already applied this patch to their tree -- it'll appear in the next release of Firefox. Could people try mozilla-firefox-2.0.0.1-r3 and report back? If the problem is fixed, then I'll add arches and get it pushed to stable. (And I'll be testing on MIPS very shortly)
It works on x86.
Hi Stuart, do you plan to release a mozilla-firefox-bin-2.0.0.1-r3 too?
Looks like its fixed with 2.0.0.2 According to https://bugzilla.mozilla.org/show_bug.cgi?id=370445 v.fixed on both branches with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2) Gecko/20070215 Firefox/2.0.0.2 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.10) Gecko/20070216 Firefox/1.5.0.10
(In reply to comment #4) > Hi Stuart, do you plan to release a mozilla-firefox-bin-2.0.0.1-r3 too? > Being a bin it's impossible to apply a patch :) For -bin we'll have to wait to the 2.0.0.2 release, which is now rc4, so it should be out soon.
This Firefox release will be handled on bug 165555 which is older. *** This bug has been marked as a duplicate of bug 165555 ***
