Weekly Edition
Return to the Security page
| |||||||||||
New security releases for Firefox and Thunderbird
Security vulnerabilities in the Firefox browser and Thunderbird mail client
are scary. Both tools are widely used, exposed to arbitrary data from the
Internet, and used with important (and confidential) information. A
widespread exploit has the potential to affect large numbers of people in
highly unfortunate ways. So, whenever the Mozilla Project fixes a set of
vulnerabilities, it's worth paying attention.
The recently released Firefox 1.5.0.4 addresses a fairly long list of vulnerabilities. Some of the most significant of those (the ones rated "critical") are:
There are also several vulnerabilities which are not considered to be quite as frightening, but which are still in need of fixing. Thunderbird 1.5.0.4 is also out, with its own vulnerability list. Only one of these is deemed critical: a double-free error on an invalid VCard which appears to be exploitable. It is worth noting, however, that Thunderbird uses much of the Firefox code base for rendering HTML, so it can also suffer from Firefox's vulnerabilities. So, in particular, if a user allows the execution of JavaScript in incoming mail (an especially bad idea which is not the default behavior), most of the Firefox vulnerabilities listed above are also exploitable in Thunderbird. There is another common theme found in all of the Firefox vulnerabilities: they can all be mitigated by turning off JavaScript. The sad fact is that executable content seems to be a hard thing to get right; it is an ongoing source of vulnerabilities in almost every context where it can be found. So it is not surprising that many people simply turn off JavaScript entirely. It is unfortunate that so many web sites are inaccessible to browsers running without JavaScript, forcing security-conscious users to enable a problematic feature they might prefer to do without. (See the LWN vulnerability entry for distributor updates addressing these problems. As of this writing, the list of updates is discouragingly short, with only Slackware and rPath getting fixed out within the first couple of days after disclosure). (Log in to post comments)
New security releases for Firefox and Thunderbird Posted Jun 8, 2006 2:34 UTC (Thu) by kfiles (subscriber, #11628) [Link] Well, it would seem that any site you would really want javascript on would be one you can trust enough to whitelist it with the NoScript extension. For all the cracking/porn sites that may use javascript, having it disabled can only be beneficial, right?
--kirby
JS unavoidable Posted Jun 8, 2006 5:52 UTC (Thu) by eru (subscriber, #2753) [Link] Not really feasible. The number of JavaScript -using useful non-p0rn sites will keep growing. After all, JavaScript is the "J" in the latest web development buzzword, "AJAX". An it seems to be in the nature of most web developers to try to employ the latest flashy development, useful or not. Personally I find that it's not such a bad thing, if neat JavaScript techniques keep them away from abominations like ActiveX or Flash. After all, JavaScript works on libre browsers without proprietary plugins.
JS unavoidable Posted Jun 8, 2006 11:25 UTC (Thu) by Dom2 (guest, #458) [Link] If only more web developers would take on HIJAX as a good idea...
JS unavoidable Posted Jun 8, 2006 17:47 UTC (Thu) by rfunk (subscriber, #4054) [Link] I agree. In the late 90s I kept Javascript turned off, but long ago thatbecame just too difficult to live with, and I gave in. I'm running into similar issues now with Flash -- I keep Flash disabled by default (and usually don't even install it), but so many sites require it now that I'm way too close to just giving in. What's worse is that many of those sites require a version of Flash that isn't even available yet on Linux.
New security releases for Firefox and Thunderbird Posted Jun 8, 2006 12:53 UTC (Thu) by liljencrantz (subscriber, #28458) [Link] It seems to me that one way of making firefox _much_ more secure would be to sandbox the entire program. If there was e.g. an SELinux policy that only allowed Firefox to read and write in ~/.mozilla and to create and write into _new_ files in ~/Downloads, the severity of most exploits would go down. Fixing cross site scripting exploits would need for firefox to run each site in a different thread, which would come at a performance cost. (Or can SELinux target individual threads of a process?)
Some of the same benefits could be had by running Firefox as a different user.
New security releases for Firefox and Thunderbird Posted Jun 9, 2006 13:38 UTC (Fri) by kingdon (subscriber, #4526) [Link] You missed file uploads (which files do you want users to be able to upload?).
But more fundamentally, this is a question of mitigating a compromise, rather than "sandboxing" in the sense of truly isolating the untrusted code. If someone owns Firefox without access to the rest of the system, they still have access to plenty. At least if Firefox has stored passwords (as it offers to by default), has cookies which allow access to sensitive sites like banking ones (as it needs to, at least temporarily, while one is logged into said site). At a perhaps lesser severity there are things like distributed denial of service, in which an owned firefox could go fetch a bunch of web pages. Having said all that, some such SELinux policy is probably a good thing, it just doesn't substitute for all the other things which need to happen.
Having several users (or even two firefox/mozilla profiles), one for online banking and one for casual web surfing is perhaps a more solid plan. But I don't know how secure and/or convenient this can be made ("is the banking instance configured to complain if you go to any site not explicitly listed?", for example).
New security releases for Firefox and Thunderbird Posted Jun 11, 2006 22:11 UTC (Sun) by liljencrantz (subscriber, #28458) [Link] I agree with every point in your post. I didn't mean to imply that an SELinux policy would be enough to secure a browser, but it would be a start.
New security releases for Firefox and Thunderbird Posted Jun 12, 2006 15:18 UTC (Mon) by kleptog (subscriber, #1183) [Link] ISTM that if the problem is w.r.t. uploading of files, perhaps there needs to be a way for the user to grant access to files on a case-by-case basis. For example, when asking for a file-upload, you could assume that any file selected by the user, firefox is allowed read-only access to.
This could be done within the UNIX system, by requiring programs that want access to files that are not normally within their scope, to ask some priveledged daemon for access. The daemon could pass the file descriptor of the selected file back to the program. A sort of file-access-agent.
Has such a mechanism ever been considered? It might not be part of SElinux since (ISTM) selinux is as much about preventing users from giving away files as it is about restricting access to priveledged files.
New security releases for Firefox and Thunderbird Posted Jun 12, 2006 16:15 UTC (Mon) by liljencrantz (subscriber, #28458) [Link] I have read suggestions like this before, and they seem sane to me.
As near as I can tell, this could be implemented transparently for the user at the GTK level by making the open file dialog spawn a separate program which has SELinux rights for reading almost anything but can't write anything, anywhere. This program allows you to select one or more files using a simple open dialog, and then outputs the resulting filenames and file content through a pipe to e.g. Firefox.
There are a few notable problems with this model:
* Performance. Startup time might delay showing of the dialog for many miliseconds, and the time taken to show the open dialog has been a focus of attention in the recent Gnome performance work done by e.g. Federico Mena Quintero (Hope I got the name right).
New security releases for Firefox and Thunderbird Posted Jun 12, 2006 18:06 UTC (Mon) by kleptog (subscriber, #1183) [Link] That's why I was referring to a file-agent-daemon, to try and draw a parallel to what ssh-agent does. Imagine a daemon where, when you ssh'd to a remote machine and ran a program there, you had a way to securely allow that program to access files on your home machine. In that case, running firefox on your own machine becomes a special case, but the general idea becomes much more useful.
Backward compatabilty is an issue, but perhaps returning names like /dev/fd/blah can reduce the problem...
Still pie-in-the-sky stuff though...
New security releases for Firefox and Thunderbird Posted Jun 12, 2006 19:02 UTC (Mon) by liljencrantz (subscriber, #28458) [Link] Is /dev/fd/BLAH general Unix or Linux specific? If the former, that combined with your user agent idea sounds like a very reasonable proposal.
But still, it's only actually useful for programs that are otherwise locked down, e.g. running as another user or in an SELinux sandbox.
|
|||||||||||