Slashdot Mirror
Unpatched Firefox Flaw May Expose Users
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."
Why would you be browsing warez sites? You are a Linux user, right? If so, you'd have all the software you ever need. That's the beauty of open source: no need for piracy.
Cyric Zndovzny at your service.
about:config -> network.enableIDN -> false
be happy!
I made a page with the supposed bad link full of dashes and all that happens, is that FF tries to do a Google lookup on "keyword:---lots of dashes here---"
This seems to be a dud exploit...
Oh well, what the hell...
Actually, I have searching from the location bar setup as default, and only thing I get is firefox opening a google search with a bunch of dashes in it. (this is on linux)
8 &q=
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
Complexity is a measure of our ignorance...
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 which clearly states the following:
No need to bring up just this bug, why not compare history for the last year on both IE6 and Firefox 1.x?
o d=11o d=4227
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)
Help Brendan pay off his student loans
Take 2 seconds to check out his proof of concept:
t ml
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).
Actually, you might be able to, most people don't know of the Greasemonkey-ish add-on to IE called "Trixie", with many of the same scripts running unmodified between the two plugins.
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."
http://www.frsirt.com/english/advisories/2005/1690
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
Go look up exploiting buffer overlows. You obviously don't know what the hell you are talking about, and you obviously know nothing of how programs run in memory. Sure the heap overflow is just crashing your browser now, only because it is accessing memory it isn't suppose to. I am sure some nop's and jmp statements could point it in the right direction ;).
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.
Here's an xxd dump of the offending HTML:
Flaw is present in firefox 1.0.6. except the way to
................ ................ .......... >.
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
For those testing on their own, *please realize* that it is not simply a dash (0x2D), but the character 0xAD.
If you followed the discussions on IRC, you'd see that people are working on the bug.
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.
My server
What about this:
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.
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
here we are in 2005 and the number one exploit across systems is still... buffer overflows.
l nerabilities.html, it looks like most security holes in Firefox are not related to low-level memory management.
Are you sure that's true? Looking at http://www.mozilla.org/projects/security/known-vu
The shareholder is always right.
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)).
Human being (n.): A genetically human, genetically distinct, functioning organism.
The bug has been disclosed by Mozilla staff and a patch fixing the reported buffer overflow has already been applied to the CVS tree, so expect a public security update very soon. In the meanwhile, as a temporary work-around, you can fully protect your browser opening "about:config" and setting the network.enableIDN preference to false, see the full story here.
There's a browser safer than Firefox, it is Firefox, with NoScript
I am sure some nop's and jmp statements could point it in the right direction ;).
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.
Any program relying on (nontrivial) preemptive multithreading will be buggy.