Slashdot Mirror
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."
I can report that the exploit doesn't work on FC4, with the latest 1.5 built from source.
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?
This slashdot-related signature is a stub. You can help kihjin by expanding it.
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...)
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.
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/
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.
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.
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
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.
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.
Beware: In C++, your friends can see your privates!
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.
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.
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.
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
Prime numbers are exactly what Alan Greenspan says they are -S. Minsky
Sorry, having just posted that, it THEN crashed when I closed the Apple tab.
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.
> 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.)
Cut that out, or I will ship you to Norilsk in a box.