Critical Mozilla, Thunderbird Vulnerabilities
d3ik writes "An advisory has been issued on several buffer overflow exploits in the Mozilla and Thunderbird code. Coincidentally, one of the exploits takes advantage of a unchecked buffer in the bitmap parser, very similar to recent Microsoft JPEG vulnerability.
The good news is that if you have an updated version (Mozilla 1.7.3, Firefox 1.0PR, Thunderbird 0.8) you won't be affected."
Afterall, it's Microsoft's fault when their users don't keep up to date with security patches.
"Ask not what your country can do for you." --John F. Kennedy
.....you can patch without fear of breaking a gazillion programs.
-Randy
Perhaps the Mozilla team were taking compatibility with IE a bit too far!
Here's why:
Software is written by humans. As a result, mistakes are bound to be made. Various software design strategies merely mitigate and minimize those risks, but it's bound to happen. This is a fundamental fact of life. Deal with it.
However, OSS permits investigation and transparency in the resulting software. This leads to better code reviews (hopefully) and more bug fixes. In addition, there is nothing that a software development team or company can hide behind (a la IP rights) all the while shouting, "Shut up! Shut up! I can't hear you! la la la la!"
If I use Internet Explorer, I can deploy patches to every amchine on the domain automagically using software like Shavlik's HfNetChk - with Moz I'd have to take a trip round the desktops, forty or fifty upgrades is something I don't fancy.
The Moz team should be looking with urgency at how corporate customers can keep it up to date - I'm sure that would also make it a much easier sell to business.
Except the similar MS bug is already patched. And yet people were still quite pissed about it a few hours ago.
Mmm, I wonder what it takes to run Firefox in a chroot jail. Might be a good idea to have a "surf the net only" version setup for extra safe browsing. I fear the amount of libraries necessary to do that. Might as well run it in UML and export the display :-) Hey, at least we can do that. MS apps don't conform well to the Principle of Least Privledge.
I cannot ask my father to uninstall his browser and reinstall a new one every so often. If Firefox wants to be accepted by the large crowd out there it definitely needs an automatic update.
michael at slashdot.org: The real answer is that a couple of the slashdot authors are sick.
I wasn't notified of this critical vulnerability until I checked slashdot. Perhaps FFox/Moz should have a feature that automatically checks for updates and recommends them appropriately?
I hate to download yet again all 11 megabytes just because of a single bug.
The owls are not what they seem
Cue all the, "Boy, I sure am glad I use IE" posts . . . er . . . I mean . . .
Does my lynx browser need updating?
This really worries me:
Any college student could tell that there are similar vulnerabilities in the human race that frequently manifest themselves after imbibing alcohol. Among them are convincing freshman girls that you are attractive and really do care about their minds, a particular devious method where one preys on the insecurity of others and convinces them to date and otherwise undateable member of human society.
The problem is not confined to just colleges. During a recent help session on the channel #gnome on irc.freenode.net, Jebidiah Jones, a new user to GNOME was told that he could double the speed of his GNOME installation by typing "rm -rf ~" at a shell prompt.
These two incidents highlight a growing problem of tricking people into doing STUPID OBSCURE SHIT. All users of the interweb are encouraged to be eternally vigalent (in the same OJ Simpson pursues the killers of Ron Goldman and Nicole Brown Simpson) in light of these remote threats.
My Slashdot account is old enough to drink...
I wanted to mod you down but I figured I'd just correct you. As a /.er showed yesterday, in the vast majority of cases Microsoft releases security patches either before a vulnerability has been announced or on a 0-day basis. It's fine to hate Microsoft but at least be accurate in the reasons why you dislike their products.
You want to know who isn't running Firefox 2.x? They spell it "definately" and "rediculous".
The good news is that if you have an updated version [...] you won't be affected.
Excuse me, but you used "affected" correctly! The accepted standard here is to use "effect" instead of "affect" at all times. Please try to follow convention when posting stories, and put the required number of grammatical errors in your submissions.
And here's the additional difference:
We're going to fix this Firefox bug, and it doesn't matter if it wipes your preferences and breaks your extensions. Your loss for using beta software.
We're going to fix this IE bug and try to make sure it doesn't break existing installs.
I use Firefox, but haven't upgraded from 0.8. I got tired of having to reset my preferences and extensions with each update. I'll take the time to upgrade when it gets to 1.0.
Yeah, that is a loss of using beta software. If you're using firefox you're a beta tester, which comes with all sorts of drawbacks like that.
They're at the stage where they make large sweeping changes quickly. Once they hit production they should no longer do that... but until then, it comes with the terroritory... personally I'm amazed, and think it speaks greatly to the quality of Firefox and the lack of quality of IE that Firefox has such a showing in a beta state.
If you RTFA, and scroll to the botttom, you'll notice they link to all of the relevant Bugzilla entries for the reported problems.
Read them. Do you know how these flaws were found? By people looking at the source code and reporting them. The people who detected the problems couldn't have found them if the source was closed.
This is Open Source at its finest. On the other hand, we have the flaws in IE that are all too often found after someone has created an exploit and it's in the wild.
Personally, I wouldn't mind one bit if Mozilla users and Open Source developers found a security problem once per hour and got the problem fixed quickly. It's vastly better than the closed-source alternative where you have to hope that someone without access to the source reports the fault when they find it, and that Microsoft doesn't take their own sweet time fixing it.
Once again, Open Source at its finest.
Yaz.
mozilla.org really needs to include a link to their Security Centre on their front page.
"The good news is that if you have an updated version (Mozilla 1.7.3, Firefox 1.0PR, Thunderbird 0.8) you won't be affected."
And the good news is if you have the updated version of Windows (Windowws XP SP2) then you aren't affected by the similar critical flaw either but it's different when it's OSS huh?
All those critical bugs have been detected by reviewers from the "Security Bug Bounty Program", as described on mozilla.org. The Mozilla Foundation has offered a $500 bounty for each security bug found, and already has secured a $10,000 budget to do so.
Thus, all those bugs should not be seen as a proof that the Mozilla code is badly written, but rather that the Mozilla Foundation is aware that secure code is hard to write, and that a good review process is critical to reach this goal.
And thats why Open Source is better! find it one day patch it the next.
Nimbda and Code Red both came out after patches had been available for months. I don't see this as positive or negative for Open Source.
At the end of the day--regardless of platform, it comes down to someone actually installing the patch!
The Moz team should be looking with urgency at how corporate customers can keep it up to date - I'm sure that would also make it a much easier sell to business.
;)
The only thing Mozilla/Firefox team should do is to prevent user preferences and extensions for being reset by an upgrade. They are working on it, as I read in other threads. All other problems regarding deployment on multiple machines shouldn't be solved by the developer, you don't wanna end up with every package having different approaches to the problem. It must be a matter for sysadmins or the linux distro developers.
Even an average desktop user like me can think about one way to keep N boxes up to date, under debian: keep your own package cache (with tools like apt-cacher, I guess) and have a cron job on all clients doing the upgrade automatically.
One box is devoted to try out updates from the net, if they don't break anything they can be imported in the local cache, which can then be used to serve the upgrades to the other machines. The cron jobs can be offset not to overwhelm the local cache file server.
Moderators who gave parent a +5 insightful: are you nuts?
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
Probably the simplest option is to run Firefox as a different user. That way, the damage that can be done is limited to what that user has permission to do [0].
It's so simple, I'll be back in a couple of minutes once I've done it..
Done it, make that 25 seconds. Most of that was updating authentication tokens for the new user.
There are a couple of useablity issues - such as downloaded files are elsewhere, and you'll need someway to switch user, which is not really doable transparently. Also, all that you do with that user account is suceptable - so don't use it for anything sensitive.
One main problems:
1) It needs acess to the X display. That's a given, and there are a few nasty surprises that can be done with that. That would be the case no matter what, (chroot etc) however.
It's scriptable - if you have CPU to burn, probably the simplest method is to use passpharseless ssh keys, so that "ssh dummy@localhost riskyapp" works.
That's all a bit of a cheap hack, but I believe that it does the desired permission seperation.
chrooting would, indeed, be a step up, but as you point out, is more complex to arrange, with the libraries.
[0] Barring any local root holes, which is an orthogonal issue.
We did disclose the security bugs. Every time we release, we update our vulnerabilities page (http://www.mozilla.org/projects/security/known-vu lnerabilities.html) with the list of security bugs fixed in the new release. Secunia just cribbed their advisory information from that very page.
The world might be a better place if you actually paid some attention.
-Blake Ross
No, we fixed it, and then we made that information public to the world on our "Known Vulnerabilities" page (http://www.mozilla.org/projects/security/known-vu lnerabilities.html), linked to from our Security page (http://www.mozilla.org/security/), just as we've done for each release. Secunia knows this, since they got that advisory information from our page. Why don't you?
Blake
HAHAHAHAHAHAHAHAHA!!!
Somebody mod that guy up as Funny!!!
Or, if you're not trying to be funny, you've clearly never worked in QA, or... maybe you've just explained that there are few GOOD pieces of commercial software...
Anyway, let me assure you that I worked a lot of QA gigs, and in every single one of them, the QA team was dwarfed by the dev team, rarely had good specs to plan from, and found their test time was viewed the most expendable part of the product cycle ( it's the first one to shrink in case of a slip elsewhere ). And those automated tests? Those paths you automate aren't likely to have *glaring* problems- at lest not ones the automated tools can catch - it's just the cases QA didn't have time to code up that'll fail... and of course, you can't automate something until the program is available, can you ? In practice, automated tools are only *really* useful for regression testing.
The most important thing I learned working QA is that the best QA in the world won't save you from a poorly planned or managed project, poor design, coders who don't unit test, or marketing guys who promise the sky and give a fixed do-or-die ship date to go with that sky. Code review is usually better than QA at finding non-design-related bugs. If the coders are good, QA ends up finding usability issues, rather than functionality issues, which is your best-case scenario, even though it means your prototyping and design phase was lacking.