Unpatched Firefox Flaw May Expose Users 390
Corrado writes "CNET is reporting on a new Firefox flaw." From the article: "The problem lies in the way Firefox handles Web links that are overly long and contain dashes, security researcher Tom Ferris said in an interview via instant messaging late Thursday. He posted an advisory and a proof of concept to the Full Disclosure security mailing list and to his Security Protocols Web site...The public bug disclosure comes just as Mozilla released the first beta of Firefox 1.5. The final release of the next Firefox update, which includes security enhancements, is due by year's end, according to the Firefox road map."
Re:Oh Crap! (Score:2, Informative)
workaround (Score:3, Informative)
be happy!
Nope - not on my v1.06 Firefox (Score:3, Informative)
This seems to be a dud exploit...
Re:Proof of concept (Score:2, Informative)
So kind of pointless exploit in this case ?
So, to protect yourself
go to about:config and change keyword.URL to http://www.google.com/search?lr=&ie=UTF-8&oe=UTF-
and keyword.enabled to true
Re:1.5 safe? (Score:2, Informative)
I'd say RTFA, but this is Slashdot after all...
If you had read the article you would have found a link to the advisory [security-protocols.com] which clearly states the following:
Re:Well, just another bug (Score:5, Informative)
According to Secunia, during 2005 IE6 has had 11 advisories while Firefox 1.x has had 18.
Unfortunately I can't get the links to work properly (graphs come up blank), so take a look at the URL's yourself:
IE6: http://secunia.com/graph/?type=adv&period=2005&pr
Firefox 1.x: http://secunia.com/graph/?type=adv&period=2005&pr
(you will have to copy and paste these URL's to make them work it seems)
For all those that can't reproduce (Score:5, Informative)
http://www.security-protocols.com/firefox-death.h
WARNING: Clicking the above link will crash firefox. It will do nothing else. The hyphens are not normal minus hyphen (the - symbol on your american keyboard will translate to 0x2d) but a soft hyphen (0xad).
Re:Well, just another bug (Score:3, Informative)
A better argument is that "In firefox, the bugs are trivial enough to be fixed with a script until it gets fixed in the main program, a matter of weeks, instead of fixing it in a script in IE, and waiting years for it do get fixed."
Re:Nope - not on my v1.06 Firefox (Score:1, Informative)
http://www.security-protocols.com/firefox-death.h
That's completely false. (Score:1, Informative)
Affected Products:
Mozilla Firefox version 1.0.6 and prior
Mozilla Firefox version 1.5 Beta 1 and prior
Mozilla Suite version 1.7.11 and prior
Re:Nope - not on my v1.06 Firefox (Score:3, Informative)
$ GET www.security-protocols.com/firefox-death.html | xxd
0000000: 3c41 2048 5245 463d 6874 7470 733a adad <A HREF=https:..
0000010: adad adad adad adad adad adad adad adad
0000020: adad adad adad adad adad adad adad adad
0000030: adad adad adad adad adad 203e 0a
Assuming the document is UTF-8 (no way of telling for sure), we can look up 0xad in gucharmap and so realise that the character that triggers the bug is really "U+00AD SOFT HYPHEN"
So you are a victim of loss of information caused by the incorrect encoding of the advisory into ASCII.
Re:Flaws (Score:1, Informative)
No, you go and look up buffer overflows.
Just randomly overwriting memory != executing code. You have to overwrite some object that controls the flow of execution, on stack buffers you're looking for return adresses, on the heap an ideal situation would be function pointers. If you think just writing "nop's and jmp statements" onto the heap means you get them executed, you're a moron.
Secondly, lets assume that a thorough analysis of the heap reveals some object that you can overwrite and could potentially redirect the flow of execution to some code that you can control..how exactly are you going to get there if all you can do is change it to 0x78787878? Go ahead, try and change the "proof of concept" to include other characters or byte values. Does it work? No.
All this is is a heap corruption bug.
Re:Proof of concept (Score:5, Informative)
Here's an xxd dump of the offending HTML:
Re:Works only in Fx 1.5beta1, 1.0.6 is not affecte (Score:1, Informative)
triget it isent a '-' but a string of 0xad see
hex view of www.security-protocols.com/firefox-death.html
0000000: 3c41 2048 5245 463d 6874 7470 733a adad <A HREF=https:..
0000010: adad adad adad adad adad adad adad adad
0000020: adad adad adad adad adad adad adad adad
0000030: adad adad adad adad adad 203e 0a
mod parent ignorent istend of insightful please
bob
Re:For all those that can't reproduce (Score:3, Informative)
Your link crashed my browser.
Important note to all... (Score:4, Informative)
For those testing on their own, *please realize* that it is not simply a dash (0x2D), but the character 0xAD.
Re:For all those that can't reproduce (Score:3, Informative)
Only for some people. It needs to specify a character set, too; the "exploit" appears only to crash Firefox when the character set is ISO-8859-1, so if your browser is set to use anything else by default, the link will not do anything at all.
Re:For all those that can't reproduce (Score:4, Informative)
no problem if set to false in about:config
Re:For all those that can't reproduce (Score:3, Informative)
MOD PARENT UP
It's true - if you leave network.enableIDN set to 'true' then the browser will demonstrate the problem. Toggle it to 'false' and the problem doesn't appear.
Re:Unacceptable (Score:3, Informative)
mconnor: we're in security firedrill mode. probably not meeting on beta2 today.
They're all busy dealing with this issue... everything else is on hold.
Re:Well, just another bug (Score:4, Informative)
0 extremely critical of 22 vulnerabilities and 4 still unpatched for Firefox
versus
10 extremely critical of 69 vulnerabilities and 19 still unpatched for IE 6.
I'm not saying Firefox doesn't have its issues, but be careful with statistics.
incorrect information (Score:4, Informative)
The bug report is now open and you can see that he reported it to Mozilla on the afternoon of the 6th. There was quite a bit of activity from top Mozilla developers and then the reporter posted the exploit publicly on the 8th.
We've determined that disabling IDN is a safe workaround and are working on supplying a small download that will take care of that configuration for the user.
- A
Re:Tell all your friends! (Score:2, Informative)
Are you sure that's true? Looking at http://www.mozilla.org/projects/security/known-vu
Re:incorrect information (Score:4, Informative)
I'd also note that Ferris's bug report (bug 307259) originally claimed that the vulnerability was a format string vulnerability, not a buffer overrun, and that the testcase he showed us was a huge testcase probably generated by a tool for generating mangled HTML (like MangleMe). What he published in his advisory wasn't analysis he gave to us when he reported the bug, but looks like it was copied from:
Re:Firefox is the fix for Internet Explorer proble (Score:3, Informative)
P(Vi) = Probability of being pwned by single vulnerability Vi = (chance of vulnerability being exploited)*(chance of user replicating vulnerability conditions).
Probability of being pwned by multiple vulnerabilities = 1 - PROD over all vulnerabilities(1 - P(Vi)).
Re:Nope - not on my v1.06 Firefox (Score:3, Informative)
Already fixed (Score:2, Informative)
Re:Flaws (Score:3, Informative)
The point that the person was trying to make (for which you rather unjustifiably called them a moron) is that you can't encode a nop or a jmp with just 0x78 bytes. That means that you can't push exploit code over into the browser to execute using this hole. That doesn't mean that it's impossible to cause a problem with this -- there is a very slim possibility that something crucial could be overwritten while keeping the program operational (for instance, suppose there is a bit somewhere nearby in memory that, if enabled, allows a remote website full script execution privileges, and a series of 0x78 bytes could overwrite that memory).
The chance of there being a away to finagle this into any kind of security exploit other than a DoS while visiting a specific website is very minimal, though. Maybe Thunderbird users could be hit by email that crashes their mail client, which would be somewhat more serious, as it would be a push DoS instead of a pull DoS.
I don't really worry about every browser flaw that comes out. I run "yum update" every couple of days, and maybe I'm vulnerable for a few days...but, hell, such is life, and I don't really want to waste lots of time worrying about some security bug -- hell, someone could just mug me for my wallet.