More on Firefox 1.5 “vulnerability”
I put vulnerability in quotes because it’s looking less like a problem. (Correct me if I’m wrong.) Here’s the situation. Both Sans and Mozilla have failed to duplicate the crash although have duplicated extremely slow browser performance. Here’s the official response from mozilla.org…
We have investigated this issue and can find no basis for claims that variants of this denial-of-service attack can cause an exploitable crash, and no evidence for this claim has been offered. There does not appear to be any risk to users or their computers beyond the temporary unresponsiveness at startup.
Along with Sans findings…
The machine I was testing this on has McAfee Enterprise 8, and Firefox would not crash. Despite my valiant efforts in disabling the protection, I couldn’t get it to crash. While annoyed that I couldn’t (short of uninstalling) get the protection disabled, it probablly is a good thing. I’ll test more when I get in the office tomorrow and have more machines to play with.
This seems to be more of a denial of service than a true buffer overflow. It looks like Firefox just chokes on page topics that are too long. Some people it hangs, other people it crashes.
Once again here are sans updated workarounds…
WORKAROUNDS:
However, the following is a workaround that should work (if it doesn’t let me know). Go to Tools -> Options.
Select the Privacy Icon, and then the History tab. Set the number of days to save pages at 0. This will disable writing anything to history.dat as far as I can tell, and should nullify the exploit. Readers have confirmed that this workaround does prevent the buffer overflow. You can also change your privacy settings to delete personal info when you close Firefox.
Another workaround is to modify prefs.js while Firefox has not been started and put in the line:
user_pref(“capability.policy.default.HTMLDocument.title.set”,”noAccess”);
Lastly, you can also run the NoScript extension, found here. (Which I have not looked at in depth.) However, there are other ways of exploiting this where NoScript might not work.
Some users have reported being unable to reproduce this error. I will test more to try to establish what makes this work and not. So far it appears Mac users are not affected by this.
HOW TO LOCATE THE PROFILE FOLDER:
If you need to delete your history.dat file (in case you tested this PoC code), it can be difficult to locate where exactly this file is.
You can find instructions for locating the profile folder at the following URL: http://www.mozilla.org/support/firefox/edit#profile.
Mozilla.org suggests….
Deleting the item from history
Open History from the Go menu
Select the item with the long title
Press the delete buttonClearing all history data
In Firefox 1.5
Select “Clear Private Data” from the Tools menu
Check the “Browsing History” box and press the “Clear Private Data Now” button
In Firefox 1.0 (also works in 1.5)
Select “Options” from the “Tools” menu
On the “Privacy” tab select “History”
Press the Clear button in the History section
So, if nothing changes, that’s the way to deal with this. It’s worth noting that the Proof of concept code had a URL with 2.5 million characters. If a site with a URL that long has been visited (is in history), it may take several minutes for Firefox 1.5 to startup.