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."

Comments

workaround

[Anonymous Coward]

about:config -> network.enableIDN -> false

be happy!

Nope - not on my v1.06 Firefox

[HermanAB]

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...

Re:Nope - not on my v1.06 Firefox

[cortana]

The advisory isn't talking about "0+002D HYPHEN-MINUS". Try the sample exploit. Freezes Firefox and Epiphany cold here.

$ 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:Nope - not on my v1.06 Firefox

[greenskyx]

Ok, here is the deal. in about:config search for idn. If you have network.enableIDN set to false this wont work. I'm not sure if I disabled that myself or if that's a firefox default. Either way you might want to make sure IDN is turned off if you dont use it.

Re:Proof of concept

[Gori]

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)

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-8 &q=

and keyword.enabled to true

Re:1.5 safe?

[beerman2k]

I dont understand. Is 1.5 safe?

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:

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 a affected
host.

Re:Well, just another bug

[DaHat]

No need to bring up just this bug, why not compare history for the last year on both IE6 and Firefox 1.x?

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&pro d=11
Firefox 1.x: http://secunia.com/graph/?type=adv&period=2005&pro d=4227

(you will have to copy and paste these URL's to make them work it seems)

For all those that can't reproduce

[revelation0]

Take 2 seconds to check out his proof of concept:

http://www.security-protocols.com/firefox-death.ht ml

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:For all those that can't reproduce

[siliconjunkie]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511

Your link crashed my browser. :(

Re:For all those that can't reproduce

[Haeleth]

WARNING: Clicking the above link will crash firefox.

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

[MrMr]

Yep, lethal if network.enableIDN is true,
no problem if set to false in about:config

Re:For all those that can't reproduce

[Jim Hall]

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:Well, just another bug

[Tezkah]

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."

Re:Proof of concept

[sprag]

Its not dashes that do it, but soft hyphens (0xad). There's a link in another thread which has the apropriate HTML, and it does hang Firefox 1.06 on Fedora 4.

Here's an xxd dump of the offending 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 .......... >.

Important note to all...

[Transcendent]

For those testing on their own, *please realize* that it is not simply a dash (0x2D), but the character 0xAD.

Re:Unacceptable

[CTho9305]

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.

Re:Well, just another bug

[adagioforstrings]

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.

incorrect information

[asa]

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:incorrect information

[dbaron]

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:

• the analysis that I did and posted in comment 2 on the bug (which was accessible to him, since he reported it), excluding the correction I made in comment 9 (when I realized the characters I was looking at were not dashes, but soft hyphens), and
• the testcase that Jesse Ruderman wrote and attached to the bug.

Re:Tell all your friends!

[jesser]

here we are in 2005 and the number one exploit across systems is still... buffer overflows.

Are you sure that's true? Looking at http://www.mozilla.org/projects/security/known-vul nerabilities.html, it looks like most security holes in Firefox are not related to low-level memory management.

Re:Firefox is the fix for Internet Explorer proble

[cagle_.25]

OK, my first computation was wrong, also. Lol.

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)).

Already fixed

[Giorgio Maone]

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.

Re:Flaws

[typical]

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.