Slashdot Mirror
2 Firefox Security Flaws Lead to Exploit Potential
Marthisdil points out a News.com story which reports that "Two vulnerabilities in the popular Firefox browser have been rated "extremely critical" because exploit code is now available to take advantage of them." Security firm Secunia reported the vulnerabilities (and the "extremely critical" rating is theirs), but the News.com story points out that thus far, "no known cases have yet emerged where an attacker took advantage of the public exploit code." Update: 05/09 20:20 GMT by T : Rebron of the Mozilla Foundation sends a correction; this is really the same flaw reported yesterday. He suggests that you glance at the Mozilla security alert on this hole (as well other alerts at the Mozilla Security Center), and says "The Mozilla Foundation has made changes to our update servers that will protect users from this arbitrary code execution exploit."
http://it.slashdot.org/article.pl?sid=05/05/08/135 217&tid=154&tid=172
Before everyone freaks out, take a look at the bug notes to get the details.
Exploitation requires the javascript bug AND a whitelisted site. The only default whitelisted site is the update.mozilla.org, and they have made changes to mitigate the problem on their end.
So unless you've whitelisted a lot of extra sites to install themes or extensions, this is not a huge risk. To be sure, disable install "Allow websites to install software" under options | web features, and if really worried, disable javascript.
Vroomm..Vrooom...
"But...IE...Disable Javascript....NOT FAIR!!"
Correct.
One report says as follows:
Because the foundation controls all sites in the default software installation white list, it has been able to take preventative action by placing more checks in the server-side Mozilla Update code and moving the update site to another domain.
The foundation said users who have not added any additional sites to their software installation white list are no longer at risk.
So one down, the other to be fixed shortly.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
There is nothing in FireFox's architecture which makes it a more secure alternative to IE.
Except for the lack of ActiveX support.
Does Microsoft offer bounties to those who find, and alert them to, security problems? Not as far as I know. This, along with the opensource nature of Firefox will eventually make it mature into a more solid product than IE is likely to be unless Microsoft changes it's attitude. Security is, and always has been, a goal with Firefox. That just isn't true of IE. Also Firefox has the benefit of 20/20 hindsight with it's design as it was designed after many important types of exploits were discovered whereas IE's codebase is much older.
:)
Overall, I think Firefox is more secure than IE and will just grow to be increasingly more secure with time. That doesn't mean it is flawless.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
From a news report:
Because the foundation controls all sites in the default software installation white list, it has been able to take preventative action by placing more checks in the server-side Mozilla Update code and moving the update site to another domain.
The foundation said users who have not added any additional sites to their software installation white list are no longer at risk.
So one down, the other to be fixed shortly.
Meanwhile I got a notice this morning that tomorrow's Microsoft security patch will fix one major flaw, but leave others unpatched UNTIL NEXT MONTH.
So much for "days of unpatched vulnerability" supposedly favoring Microsoft.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
No, these are XUL vulnerablilities, which are not present in Gecko, only in Mozilla/Firefox. I can make a FileSystem ActiveX in Javascript and that's IE's fault, for anoyher example.
Guy asked me for a quarter for a cup of coffee. So I bit him.
There is however a reason why Firefox is more secure (at least in the long term) than IE, and that is the fact that FF is open source. Unlike the IE ones, FF exploits get patched in a timely manner. Remember, security can't be measured by the overall number of exploits, but by the the number of exploits unpatched. And considering that FF has only quite recently been introduced to general usage, I find it quite good that these exploits have been found and patched in such an small time frame.
Note that all of your extensions, bookmarks, themes etc are stored in one directory (on Windows, it's in %appdata%/firefox/, or something - I do't have access to a Windows machine right now) so you just need to carry this directory around with you - no need to manually install extensions etc every time you do a new install.
Three syllables: ActiveX. If a "feature" is so bug infested that it's worse than useless, can you consider it a bug?
Make sure everyone's vote counts: Verified Voting
While the hole exists in Mozilla, Mozilla by default ships with an empty whitelist, making it non-exploitable.
My server
Works for me, I visit slashdot more often than MOzilla.org.
.... How about a firefox plugin that automatically informs me when an exploit is found?
I'd rather get a headsup here, or even better yet
On Saturday, the Mozilla Update team, plus some Mozilla devs, took steps which prevented all published exploits we'd found from working. On Sunday, Mozilla Update was moved to an untrusted URL; as a result, users who have not added other sites to their whitelist should now be safe from the remote code execution attack.
My server
That is incorrect. Only one of the two bugs is a problem with the Firefox user interface. The other bug (cross site scripting) is a Gecko problem.
Tools/Options/Web Features/"Allow web sites to install software" - uncheck it. I don't know why this isn't unchecked by default.
It takes just a moment and an action to destroy. It takes some time and thought to create.
But I actually need to know about this....I have the good fortune to admin no copies of IE.
This is NOT a signature.
XUL isnt as bug infested as ActiveX, but it is conceptionally almost as dangerous. Be prepared to see more fun stuff with XUL.
Yeah - it could even put a little red "update" button on the taskbar whenever ... oh. Right.
The posted exploit code stopped working several minutes after posted on slashdot. The exploit code won't do anything at all.
Reposting the story ad nauseum won't make it any more interesting or useful.
Firefox bugs get on the front page when they are exploitable in theory (this exploit here also worked only for a couple of hours because Mozilla's servers have been modified so Firefox is redirected to a non-whitelist site) while IE bugs get on the front page only when they cause serious mass infections.
Another post mentions that someone is claiming an 0-day exploit in the wild for these issues.
:)
From BT:
Firefox Remote Compromise Technical Details
Before I start, I need to say that this thing has been patched on Mozilla's server. If you take a look at any of the extension install pages on their site, you will see that the install function has a bunch of random letters and numbers after it. Even though this would probably be an easy thing to bypass, I am not going to attempt it because of the uselessness of such a bypass. A patch is already in development and so any more work going into fine-tuning this exploit would be a waist of time.
There are three core vulnerabilities being used in my example. A friend of mine (Michael Krax, http://www.mikx.de/ helped me with the research.
To understand why the example works, one must understand the basics of how Firefox works. Everything you see in firefox is essentially a webpage being rendered by a compiler. This is what the gui is made of, and this is why firefox is so easy to customize. However, it also allows for some security bugs. If one could get one of the chrome pages to request a javascript:[script] url, that individual would be given complete access to the system because chrome urls are given full rights in firefox. My example works by tricking the addon install function into displaying an icon with a javascript url.
However, this would not be enough to compromise the system. By default, the install feature only works when called from a page within update.mozilla.org or addon.mozilla.org. Therefore, another (cross site scripting) vulnerability had to be found to call the install feature from mozilla.org. This vulnerability navigates to a javascript page and displays a link (pointing to a mozilla.org page) within a frame that follows the user's cursor. After the user clicks, the link is navigated to, which fires the onload event. This is a buggy event in Firefox because with it we can now access certain parts of the window object that we shouldnt, such as the history object. After the page loads, we use the history object to navigate backwards to the javascript page. The javascript is executed again, now from update.mozilla.org because when we navigated backwards, we essentially navigated to a javascript:[script] page. Now we call the install addon feature, which displays a dialog with det
ails of the requested addon, including an image with a specified image. This image points to a javascript:[script] url, which gets executed in the context of chrome. Now we have compromised the system
Whew, that was quite a mouthful.
I am still trying to gather all the details as to how my research was leaked, but recent conversations are leading me to believe that it was a misplacement of trust, not a server compromise. However, I do not want to jump to conclusions too quickly, as this will only lead to more problems. That's all I will say about that subject, as I don't want to offend anybody.
Also, I would like to let everyone know that this is not the only vulnerability that Mikx and I have found. We still have a couple of tricks up our sleeves, and you can be sure that we will not make the same mistake twice.
If you want to see the original PoC, here is the url:
http://greyhatsecurity.org/vulntests/ffrc.htm
Paul
Greyhats Security
http://greyhatsecurity.org/
Thing is: ActiveX is "broken as designed", whereas alternatives may be "broken due to bugs": in latter case it can be fixed, and exploits are generally more limited in scop.e
Actually that was an accurate statement. A much improved update system is scheduled for 1.1: http://wiki.mozilla.org/Firefox:1.1_Software_Updat e_Upgrades
Right back at you.
There's working exploit code in the comments to this very storyI guess you missed the part where Mozilla Foundation has corrected the problem on their servers, and given instructions to take any third party websites off the whitelist? The exploit code simply has no effect if that basic precaution is followed.
While the above mentioned fixes and workarounds aren't perfect, they do eliminate the problem for now. A more thorough comprehensive fix is under development.
This is no worse than that IE exploit that was redirecting people to that scammer site in Russia (forget the name of the exploit). MS issued a "fix" which didn't address the flaw in the software at all - they basically just added that one specific scammer site to the hosts-deny list (Yes I know that's not perfectly accurate, but it's basically what they did)
BTW, nobody here is impressed with your pottymouth language.
TommyOpen Source for Open Minds
Actually, most IE exploits are discovered by third party security firms, such as F-prot and Secunia. It's often months between the discovery of the flaw and a solution - you just weren't told there was a problem.
Black hat hackers also have debuggers. They can find IE exploits as easily as those third party security firms. It all comes down to who finds it first - white hat or black.
The ratio of white hat vs black hat hackers working on an app has a lot to do with how potentially insecure it is, and Firefox has many, many more whitehats than IE.
TommyOpen Source for Open Minds
Mozilla has a transparent bug tracking system
Except for the security problems, which they don't allow the public to see.
Except MS closed the IE department after 6 was released, other people got stuck maintaining the codebase for bugfixes & the like.
They killed it because the Longhorn team was including a ground up IE replacement. They did it ground up because IE couldn't get integrated tightly enough into the OS for the Longhorn folks comfort. Certainly gives me warm fuzzies over Longhorn, given that IE's problem all along has come from the OS integration.
Anyhoo, since Longhorn is a Microsoft OS project, it's long overdue - when it passed a year, and security exploits because such a PR problem that Microsoft implemented their once-a-month-patch schedule (there's that warm 'n fuzzy feeling again), they rounded up a team to start working on IE full time again. Of course they're working on IE7, other people still have their jobs maintaining IE6.
Trust me, Microsoft doesn't allow departments to go live in caves. The political infighting alone requires them to see daylight on a consistent basis, and Microsoft has managers, managers managing managers, managers managing them, etc. - all require frequent status updates and validation.
Think of Microsoft as the merger of Dilberts and Goldfingers companies and you're not far off from the average workday.