Unpatched Firefox 1.5 Exploit Made Public

ThatGuyGreg writes "C|Net is reporting that an unpatched exploit in Firefox 1.5 has been made public, making it very easy for ne'er-do-well-sites to cause your browser to crash on startup with a single visit. Until a patch is released, it is recommended that you disable your history.dat file."

FC4, 1.5

[(1+-sqrt(5))*(2**-1)]

I can report that the exploit doesn't work on FC4, with the latest 1.5 built from source.

DOS

[kihjin]

The 'exploit' seems only capable of a Denial of Service. There's no proof to indicate that malicious code could be executed.

Plus, read this (from the article):

"We have gotten no independent verification that it crashes (Firefox), but there have been a lot of attempts to try," Schroepfer said.

So, this is all very hypothetical then?

Not an "exploit"

[joetainment]

This isn't even related to security. Its just a bug.... lots of apps crash when something happens. Doesn't mean its ok, but it doesn't represent a security issue does it? (Unless I'm missing something...)

Really

[jupiter_ganymede]

Is it just me or is this a pretty worthless report? I can't really see this as being an exploit anyone would care about unless you happen be work for a certain company in Redmond.

Good test for the new Update System

[brandonp]

This will be a good test for the new Update System that was implemented in Firefox 1.5. Too bad it will need to be utilized so soon.

With the speed that the Firefox developers release their fixes and the ease of getting those fixes with the new system, I hope this will develop as proof of how well Firefox can handle these situations.

--
Brandon Petersen
http://www.brandonpetersen.com/ [brandonpetersen.com]

Re:Only crashes?

[courtarro]

There are plenty of browser denial-of-service bugs, but few of them can actually render your browser useless upon every execution. This one has a lasting effect that's more significant that the old "do while(true) alert;"-style DoS attacks. A single double-click won't fix this one; you have to delete your old history.dat file.

Re:Only crashes?

[Anonymous Coward]

If it causes a crash, it's entirely likely that some malicious code could be injected into memory when that happens! If so, you're potentially up shit creek.

It's completely retarded...

[ninja_assault_kitten]

The guy who reported it called it a 'buffer overflow' and clearly had no understanding of what it actually meant.

which
most users won't figure out.

this proof of concept will only prevent someone from reopening
their browser after being exploited. DoS if you will. however, code
execution is possible with some modifcations.

Tested with Firefox 1.5 on Windows XP SP2.

ZIPLOCK

-->

heh
function ex() {
            var buffer = "";
              for (var i = 0; i ZIPLOCK says CLICK ME

A crash can often lead to an overflow exploit

[MushMouth]

When an app crashes (firefox does quite often for me) it means that it is doing something that the programmer didn't expect. That could be all sorts of things, from taking all the cpu, to writing to memory that it shouldn't be. Most overflow exploits started as mere crashes.

Re:Only crashes?

[Jugalator]

Crashes may be signs of buffer overruns and access violations, which is a bad thing not only from the app's and user's perspective, but also from a security perspective, e.g. if the memory space was prepared earlier with malicious code.

Re:Only crashes?

[Thundersnatch]

The vulnerability is incorrect handling of input. In this case, the only *exploit* published so far is a DoS. But obviously there's something very wrong with the input validation in the code, and remote execution may be possible with a more clever exploit.

Witness the recent IE vulnerability, which MS didn't patch quickly because it was "only a DoS vulnerability". Of course, it turned out it was possible to execute code with the vulnerability, it just took a while for a better (worse?) exploit to be crafted.

Stop the stupidity

[NineNine]

Another tip for you: if you remove the gas pedal from your car, you won't have any crashes! Really!

DOWNLOADING MORE SOFTWARE to intentionally disable part of a program that is supposed to work is 150% unacceptable.

Jesus, how bad does software have to get before people finally start to not use it? Luckily, I didn't pay anything for my Firefox installations, so I can't really bitch. But I CAN look at other, less buggy alternatives (like IE) that also offer useful features that Firefox doesn't, like Active X.

Some exploit.

[bradbeattie]

I recognize that it can cause inconvenience, but come on. Exploits in IE typically result in executing arbitrary code on the user's computer. I guess this is just another argument as to why system diversity is important. If no browser had more than 20% of the market it'd be difficult to target a large portion of internet users.

Re:A crash can often lead to an overflow exploit

[Anonymous Coward]

Even if most overflow exploits start as crashes, it doesn't mean most crashes are overflow exploits. Certainly worth investigating, but assuming that every crash is an exploitable vulnerability and publishing a news story based on that assumption is dumb.

Re:A crash can often lead to an overflow exploit

[pclminion]

Most overflow exploits started as mere crashes.

While that is true, this could also be a simple null pointer dereference, caused by incomplete error handling in the code somewhere. Those sorts of failures are typically not exploitable.

Just because A implies B, does not necessarily mean that B implies A. All overflows are crashable bugs, but not all crashable bugs are overflowable.

It's easy enough to find out -- load the core file into gdb and look at the instruction that crashed. If it's a null reference, chances are this bug is no big deal.

Must be joking

[Charles Dodgeson]

The effect makes restarting Firefox very very slow (several minutes). I've just tested on OS X and on SuSE 9.3. Once that is done you can clear history through Prefences. If you don't want to wait, you can remove or manually edit history.dat.

The claim of a buffer overflow is nonsense. I suspect that that claim is a joke. The only thing that makes this mild borking work is a very long document title. In setting that up, the author uses a variable called "buffer" and "buffer2". Just because a JS variable gets named "buffer2" and gets set to something very long doesn't make this a buffer overflow. I like to think that the guy must be joking, instead of actually being that stupid.

But in the end, there is a bug to be fixed in Firefox

CORRECTION

[MooUK]

Sorry, having just posted that, it THEN crashed when I closed the Apple tab.

Why focus on JavaScript?

[Kelson]

Sure, the proof of concept uses JavaScript. But the problem itself has nothing to do with scripting. One could easily generate a 2.5MB HTML file with a really long title. 2 million "A"s in a row will probably compress pretty well, so if you serve it with on-the-fly compression, it doesn't have to take much extra time or bandwidth to retrieve.

Bingo: exploited with no scripting involved at all.

Re:Only crashes?

[jonadab]

> Just because you can make a program crash, doesn't mean you can exploit it

No, it doesn't mean that *necessarily*; however, there is historically a significant likelihood that such *might* be the case. The most recent IE remote arbitrary code execution exploit was formerly just a denial-of-service attack that for one reason or another never got patched, and eventually someone figured out how to make exploit it in a way that allows arbitrary code to be injected and executed. There are many other examples over time of cases wherein a flaw in some program or another, when initially discovered, was only a denial-of-service (or perhaps not even proven exploitable at all) but code injection and execution developed as a later, more sophisticated exploit of the same vulnerability.

This should definitely get fixed, preferably *before* anybody discovers a way to do more malicious things than DOS with it. (And I have little doubt it will be fixed, probably quite soon, if past history is any indication of future performance.)