Weekly Edition
Return to the Security page
| |||||||||||||
A Firefox zero-day vulnerability
The Mozilla Security Blog warns
of a new Firefox vulnerability which is already being exploited.
"Users who visited an infected site could have been affected by the
malware through the vulnerability. The trojan was initially reported as
live on the Nobel Peace Prize site, and that specific site is now being
blocked by Firefox's built-in malware protection. However, the exploit code
could still be live on other websites." Disabling JavaScript (or
running NoScript) will block exploit attempts.
(Log in to post comments)
A Firefox zero-day vulnerability Posted Oct 27, 2010 14:35 UTC (Wed) by fuhchee (subscriber, #40059) [Link]
I hope Firefox doesn't become the sendmail of the 2010s.
A Firefox zero-day vulnerability Posted Oct 27, 2010 15:03 UTC (Wed) by nix (subscriber, #2304) [Link]
Hasn't it already had many more security holes than sendmail?
(Its only saving grace is that its security holes don't grant immediate elevated-privilege access, and are rarely used to write worms... but most attackers don't want either of those things.)
A Firefox zero-day vulnerability Posted Oct 27, 2010 15:27 UTC (Wed) by gerv (subscriber, #3376) [Link]
Firefox is an order of magnitude larger, a lot more complex, and takes at least 15 times as many different forms of input (HTML, XHTML, CSS, JavaScript, SVG, MathML, JPEG, PNG, GIF, ICO, Vorbis, Theora, VP8, WAV, SMIL) as a mailserver. All those forms of input have complicated specs. It has 400 million installs, and deals with people's sensitive financial information, and is therefore a very tempting target for hackers.
In addition, number of vulnerabilities is a much worse measure of risk than "days of vulnerability" - how many days in a year users of that software are vulnerable to a critical bug, before a fix is provided. In 2006 (no-one has done the study since that I can find), it was Firefox: 9, IE: 286.
1 vulnerability is 1 too many, but you could at least try and compare apples with apples. :-)
Gerv
A Firefox zero-day vulnerability Posted Oct 27, 2010 16:14 UTC (Wed) by nix (subscriber, #2304) [Link]
Oh, yes, I'm quite aware that this is a completely useless comparison in as many ways as you care to measure it, but every day is a good day to be facetious :)
A Firefox zero-day vulnerability Posted Oct 27, 2010 15:35 UTC (Wed) by mstone_ (subscriber, #66309) [Link]
kinda late for that
A Firefox zero-day vulnerability Posted Oct 27, 2010 15:42 UTC (Wed) by did447 (guest, #49454) [Link]
Not sendmail but Windows, anyway it's the same model: no memory protection, everything run as the same user, have to restart it after a couple of days, a great OS.
Disable javascript or use noscript? They could have added run a different browser.
A Firefox zero-day vulnerability Posted Oct 27, 2010 16:11 UTC (Wed) by bjacob (subscriber, #58566) [Link]
Is Firefox bashing the new trend, or what? Come _on_, zero day vulnerabilities happen, deal with it, in Firefox like in any other large piece of software, switching browsers won't do anything about it.
A Firefox zero-day vulnerability Posted Oct 27, 2010 17:11 UTC (Wed) by ewan (subscriber, #5533) [Link]
Switching browser would avoid you running into this particular bug before a fix is released, which is all the Mozilla suggested mitigation of disabling Javascript is intended to do.
A Firefox zero-day vulnerability Posted Oct 27, 2010 17:14 UTC (Wed) by did447 (guest, #49454) [Link]
They ask for it, no?
From the blog
* Disabling JavaScript in Firefox
Great advices, err no, that's PR damage control.
With Firefox market share and today Web:
In the meantime, users can protect themselves by doing either of the following:
would be better.
A Firefox zero-day vulnerability Posted Oct 27, 2010 18:05 UTC (Wed) by joib (guest, #8541) [Link]
So, for comparison, does IE, Chrome, Opera, Safari and whatnot recommend that users switch to another browser if/when they have a serious vulnerability?
A Firefox zero-day vulnerability Posted Oct 27, 2010 19:13 UTC (Wed) by fuhchee (subscriber, #40059) [Link]
That would be a miracle on 34th street.
A Firefox zero-day vulnerability Posted Oct 27, 2010 19:05 UTC (Wed) by mikov (subscriber, #33179) [Link]
I wonder what part of the JavaScript vulnerabilities would have been avoided had JavaScript been designed with a proper sandbox model (like the JVM) from the start?
Of course this applies to all browsers - it seems to me that retrofitting security to a fundamentally insecure JavaScript and DOM model is what they are all doing. It is not an approach that inspires confidence.
A Firefox zero-day vulnerability Posted Oct 27, 2010 20:35 UTC (Wed) by brugolsky (subscriber, #28) [Link]
Where would W3C get its egoboo fix if they didn't insist on reinventing everything from the IBM 3270 to LISP machines, Smalltalk, and Display PostScript, poorly. Too many years of "hey, look what I can do with this cute syntax that makes my immediate problem easy" and too little thought given to coherent (and secure) semantics.
A Firefox zero-day vulnerability Posted Oct 27, 2010 21:06 UTC (Wed) by anselm (subscriber, #2796) [Link] The W3C didn't invent Javascript – Netscape did. When Javascript first came out, the W3C bigwigs were absolutely horrified. Robert Cailliau called it »the only programming language worse than C«. Tim Berners-Lee was, to put it kindly, unenthusiastic about client-side programming in Web pages in the first place.
Brendan Eich Posted Oct 27, 2010 23:19 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
More specifically Brendan Eich. Here's a recent example of him defending himself
http://jwz.livejournal.com/1307198.html?thread=23007038#t...
I'm glad nobody is building entire platforms on top of any languages /I/ hacked together in less than fortnight, because lack of natural overflow from integers into BigNums is nothing compared to what you'd be stuck with if it was all on my shoulders.
Brendan Eich Posted Oct 28, 2010 0:39 UTC (Thu) by anselm (subscriber, #2796) [Link] I think the name really says it all already. »Hey, let's call the thing JavaScript – Java is the big thing now and we'll just hang on to that for the ride! Who cares if the language is nothing like real Java.« If they'd called their browser »Javigator« it might even still be there.
Brendan Eich Posted Oct 28, 2010 14:34 UTC (Thu) by gerv (subscriber, #3376) [Link]
You think you are joking, don't you?
http://news.cnet.com/Netscape-sharpens-Javagator-plans/21...
(Date: December 1997)
Gerv
Javagator Posted Oct 28, 2010 18:58 UTC (Thu) by dag- (subscriber, #30207) [Link]
Thanks for making me smile ;-)
Brendan Eich Posted Oct 31, 2010 23:19 UTC (Sun) by KaiRo (subscriber, #1987) [Link]
Just that Brendan was AFAIK not naming it this (he called it "Mocha", I think) and was quite unhappy at first with the "JavaScript" name Netscape marketing did put on it - but then I only know all that from hearsay...
A Firefox zero-day vulnerability Posted Oct 28, 2010 22:33 UTC (Thu) by brugolsky (subscriber, #28) [Link]
I'm aware of the history, which makes it all the worse, since plenty of folks understood that it was a terrible hack, and yet it was enshrined as a de facto standard anyway, when the web was young. Essentially zero thought given to document semantics, security, location transparency, RTT latency, ..., despite the history of 3270, X11, NeWS, LISP machines, etc.
So now we have huge application stacks built on a wildly divergent array of technologies that each should have received at best a middling grade on a two-week-long undergraduate CS assignment and then gone into the trash bin.
Sometimes worse really is just plain worse. :-/
-Bill
A Firefox zero-day vulnerability Posted Oct 28, 2010 23:09 UTC (Thu) by anselm (subscriber, #2796) [Link] Yes, but at the time the only viable alternative would have been VBscript (or something similar out of Microsoft), so maybe we can count ourselves lucky after all.
A Firefox zero-day vulnerability Posted Oct 28, 2010 23:21 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
remember that it's primary competition at the early stages was Active X
Surprisingly enough... Posted Oct 27, 2010 22:06 UTC (Wed) by khim (subscriber, #9252) [Link] Actually very very few browser vulnerabilities are vulnerabilities JVM can prevent. In fact number of pure JavaScript-interpreter vulnerabilities and Sun JVM vulnerabilities is comparable and JVM is probably more vulnerable, not less (because it's more complex). Most vulnerabilities are of sort where some object is given access to properties which is should not have - and the same class of vulnerabilities exist in Java software too. I'm not a big fan of JavaScript but as far as web security is concerned... no, JavaScript is not the biggest problem by far.
Surprisingly enough... Posted Oct 27, 2010 23:48 UTC (Wed) by mikov (subscriber, #33179) [Link]
I doubt that. JavaScript and the browser are literally intertwined. There is no sandbox of any kind. The majority of JavaScript calls are going directly into C/C++ code, without any structural security framework. That is _nothing_ like the JVM sandbox.
Surprisingly enough... Posted Oct 28, 2010 8:04 UTC (Thu) by alankila (subscriber, #47141) [Link]
In practice if you had JVM and the browser intertwined just like you have javascript vm and the browser mixed today, it would be likely that JNI would be used to call the browser internals just the same. I don't see what you get by switching the javascript vm to the java vm.
Surprisingly enough... Posted Oct 28, 2010 20:53 UTC (Thu) by mikov (subscriber, #33179) [Link]
It is simply a matter of design approach. Due to the way that JavaScript has developed over the years, there is no JavaScript sandbox - JavaScript is just a part of the browser, with, as you say, full access to all its internals. Ad-hoc security checks have been added incrementally to some of the native functions that JavaScript calls, but there is no real separation between browser and JavaScript.
Had JavaScript been designed from the beginning as an independent sandboxed VM, with clear boundaries, explicit security policies and automatic mechanics to enforce them, we would have something different today. It wouldn't have the same APIs and capabilities it has today, or they would be expressed differently, with granular permissions, etc.
Another aspect is that a huge part of the JVM's robustness is due to most of it is actually implemented in Java, which being a safe language automatically precludes a large segment of security vulnerabilities. JavaScript is too limited to implement its own libraries.
And if people start claiming that JavaScript is as fast as C/C++ these days, think about this: how practical is it to write a Jpeg decoder in JavaScript? The way I see it, this is the only way to protect against all buffer overflows, etc.
Surprisingly enough... Posted Oct 29, 2010 6:46 UTC (Fri) by khim (subscriber, #9252) [Link] Had JavaScript been designed from the beginning as an independent sandboxed VM, with clear boundaries, explicit security policies and automatic mechanics to enforce them, we would have something different today. That "something" is called Flash (well, Java Applets tried to do that too but were such a huge PITA that everyone forgot about them). I can not say I'm impressed by it's security. Another aspect is that a huge part of the JVM's robustness is due to most of it is actually implemented in Java, which being a safe language automatically precludes a large segment of security vulnerabilities. This is good plan. The only problem with it: the system which makes language "safe" is so complex that there are lots of bugs in it so you just move security holes around. And if people start claiming that JavaScript is as fast as C/C++ these days, think about this: how practical is it to write a Jpeg decoder in JavaScript? The way I see it, this is the only way to protect against all buffer overflows, etc. Not at all! Just put the whole thing in seccomp sandbox and that's it. No need to develop complex JVM (which does not guarantee safety anyway), no need to rewrite all libraries. BTW this is exactly what Chrome does if the Linux is new enough. Java tales are getting old. Even Android dropped Java as far as security is concerned (they are using Java language to lower learning curve, but their security is built around good old processes and UIDs, not around in-JVM permissions and security contexts).
Surprisingly enough... Posted Oct 29, 2010 15:18 UTC (Fri) by nix (subscriber, #2304) [Link]
seccomp is getting *used* for something? Great! I always thought it was a real shame it was only used by Andrea's aborted distributed-computing-with-Linux scheme.
Surprisingly enough... Posted Oct 29, 2010 20:34 UTC (Fri) by mikov (subscriber, #33179) [Link]
You are mistaken about the JVM's complexity leading to vulnerabilities. Hardly any vulnerabilities ever have been caused by bugs in the JVM itself. They are usually caused by bugs in JNI code or fringe issues like security policies and configuration.
JVM's primary strength isn't actually in providing a sandbox for untrusted code - it is in allowing trusted code to run securely so that bugs in the trusted code do not lead to vulnerabilities.
You need to have a secure trusted API that you provide to the untrusted code you load from the Internet. If that API is implemented in C, it will _never_ be secure.
Similarly, while I do like the concept of a OS-level application sandbox (seccomp or other means), it doesn't solve the problem. Firstly, it is very inconvenient and costly, and secondly, at least in Chrome's case, the secure API available to it are still implemented in C. I prefer the approach taken by NaCl.
Surprisingly enough... Posted Oct 30, 2010 19:09 UTC (Sat) by khim (subscriber, #9252) [Link] You are mistaken about the JVM's complexity leading to vulnerabilities. Hardly any vulnerabilities ever have been caused by bugs in the JVM itself. You mean all these "verifyer vulnerabilities", "Jython JVM crashes" are myths? I don't think so. Every time you see things like "that problem arises when Sun JVM performs some optimizations during bytecode compilation, which are correct in terms of JVMS, but dont compatible with Jython" you can read is "we have a security hole here, but to exploit it you need to craft .class file by hand without use of javac compiler". I know such things happens A LOT in Harmony development and I fail to see why Sun's JVM will be significantly different. JVM's primary strength isn't actually in providing a sandbox for untrusted code - it is in allowing trusted code to run securely so that bugs in the trusted code do not lead to vulnerabilities. Wow. Cool. So we can write trusted code and not think about fringe cases or strange situations... but... They [the vulnerabilities] are usually caused by bugs in JNI code or fringe issues like security policies and configuration. Looks like no, trusted code still must be painstakingly reviewed and checked. So what's the profit? You need to have a secure trusted API that you provide to the untrusted code you load from the Internet. If that API is implemented in C, it will _never_ be secure. Well, this is what Google does. I think we'll see if it's possible to do or not in a few years. Similarly, while I do like the concept of a OS-level application sandbox (seccomp or other means), it doesn't solve the problem. Firstly, it is very inconvenient and costly, and secondly, at least in Chrome's case, the secure API available to it are still implemented in C. I prefer the approach taken by NaCl. Well, NaCl offers C API and if this list is any indication it'll use seccomp too.
Surprisingly enough... Posted Oct 31, 2010 1:40 UTC (Sun) by mikov (subscriber, #33179) [Link]
I haven't followed Harmony, but free JVM implementations usually ignore the verifier, as it is complex to implement while not benefiting valid code. I would speculate that is why Harmony suffers from these problems, same as gij, gcj, Kaffe, etc.
I will give you that there are such problems in Sun's JVM as well. I don't think many of them translate into security vulnerabilities though.
Your main argument is that a virtual machine is too complex to be a net benefit for security. I think this has been shown to be false by lots and lots of real world applications.
In any case, I am not advocating for literally using the JVM, as is, instead of JavaScript in the browser. I am complaining about the architecture of the whole thing. To address your immediate concern about .class vulnerabilities: code could still be distributed in source form.
seccomp, while very cool, does not solve the problem completely - it just moves it. It is the same as relying on the kernel to be completely bug-free.
Surprisingly enough... Posted Oct 31, 2010 16:45 UTC (Sun) by mjw (subscriber, #16740) [Link]
Some free software java runtime implementations, like gij and ikvm, have always had java byte code verifiers. There is even a free software GPL testsuite Mauve http://www.sourceware.org/mauve/ that includes various tests to make sure it works correctly. And of course icedtea/openjdk as reference java implementation includes one.
Surprisingly enough... Posted Oct 31, 2010 20:17 UTC (Sun) by mikov (subscriber, #33179) [Link]
That is not true, as far as I know. The verifier is always added late in the game, for completely understandable reasons I should say - the verifier itself is more complex that the entire bytecode interpreter.
Surprisingly enough... Posted Oct 31, 2010 20:42 UTC (Sun) by mjw (subscriber, #16740) [Link]
Seems all the free byte code verifiers out there are actually pretty old.
Here is the ikvm byte code verifier written in c#:
Here is the gij one written in c++:
The mauve verify testsuite is here:
There are even a couple of (stand alone) byte code verifiers written in java. bcel and asm contain one for example.
And of course icedtea/openjdk contained one from the start also.
Then what's the profit? Posted Nov 1, 2010 15:58 UTC (Mon) by khim (subscriber, #9252) [Link] I will give you that there are such problems in Sun's JVM as well. I don't think many of them translate into security vulnerabilities though. These problems are exactly the same as buffer overflow problems in C: yes, there are mitigation techniques, but they don't always help and more vulnerabilities then you can imagine can be exploited. I have a friend who's developing code which is instrumenting .class files. You'll not believe how easy it is to crash the JVM - without even trying. And you want to say this will be our security guard? Don't make me laugh. Your main argument is that a virtual machine is too complex to be a net benefit for security. I think this has been shown to be false by lots and lots of real world applications. Languages and technologies chosen for "real world application" (I mean commercial ones) correlate more to the PR budget, not to the quality of stuff. Where technical excellence is more important (FOSS world) Java is not all that popular. To address your immediate concern about .class vulnerabilities: code could still be distributed in source form. Then why spend resources with bytecode? Native compilation like V8 works just fine. seccomp, while very cool, does not solve the problem completely - it just moves it. It is the same as relying on the kernel to be completely bug-free. Seccomp reduces attack surface of the kernel so much that the remaining part can be made bug-free with large enough effort. More: you can decide what to put inside of sandbox and what to put outside. When you put the whole renderer (with Javascript and may be even plugins) in seccomp sandbox you need significantly simpler interface between renderer and rest of the system (compared to what Java separated from DOM will require). Yes, seccomp is not panacea but it's step in right direction. JVM is step in wrong direction, plain and simple.
Then what's the profit? Posted Nov 1, 2010 21:59 UTC (Mon) by mikov (subscriber, #33179) [Link] Languages and technologies chosen for "real world application" (I mean commercial ones) correlate more to the PR budget, not to the quality of stuff. Where technical excellence is more important (FOSS world) Java is not all that popular. To put it mildly, this claim doesn't at all correspond to my experience, which is more than two decades with projects in C, and about a decade in Java. But experience is subjective of course, so I don't think I can use it to persuade you :-) Seccomp reduces attack surface of the kernel so much that the remaining part can be made bug-free with large enough effort. More: you can decide what to put inside of sandbox and what to put outside.Again, that is the same as saying "I trust the kernel to be 100% free, so root exploits from non-privileged code are impossible". Not very realistic, don't you agree? Anyway, I think that we both have exhausted our respective objective arguments, so we should agree to disagree... It was informative - I definitely got some more insight into the issue, making my position more nuanced.
Surprisingly enough... Posted Oct 31, 2010 23:22 UTC (Sun) by KaiRo (subscriber, #1987) [Link]
AFAIK, the number of days the Sun JVM was exposed to critical security vulnerabilities in the last year was significantly higher than the same measure for Mozilla's JavaScript engine. That somehow doesn't make me buy your argument.
A Firefox zero-day vulnerability Posted Oct 28, 2010 1:25 UTC (Thu) by kripkenstein (subscriber, #43281) [Link]
> I hope Firefox doesn't become the sendmail of the 2010s.
You're kidding, right?
For a complex piece of software like a web browser, with a huge attack surface, it has an excellent track record for security. In fact a fix for this particular vulnerability has just been issued.
Sendmail was developed without concern for security (back in those days, who was?), Firefox is the opposite. They put a ton of effort into that. No, Firefox isn't perfectly secure. No web browser, OS, or other complex software is.
A Firefox zero-day vulnerability Posted Nov 4, 2010 8:37 UTC (Thu) by NikLi (guest, #66938) [Link]
A complex piece of software is not the excuse.
They've been constantly adding new unsecure features to all WEB 2.0 related standards every day. For example, CSS3 supports "remote fonts" where the fonts that a page should use are specified by an URL in the stylesheet. Imagine how many new interesting vunerability possibilities in the freetype engine this opens!
Excellent record for security? Every week we get a new set of serious firefox vulns. Makes you wonder if there are any undisclosed ones, if the attackers got to them first, if your firefox has been already pwned and clicking on "fetch updates" will fetch backdoors, etc.
Given the paranoid security of browsers, for me the best option is:
qemu running windows XP. In there i run firefox and I have different hard disk images. The "unsecure one" which i don't care and the secure one for credit cards, etc. Hard disk images are deleted monthly and restored from base images.
On linux I use only konqueror and only for very specific pages.
A Firefox zero-day vulnerability Posted Oct 27, 2010 23:55 UTC (Wed) by merge (subscriber, #65339) [Link]
It has been fixed quite quickly: http://www.mozilla.com/firefox/3.6.12/releasenotes/ Now it's the distros' turn.
Debian (big thanks to Mike Hommey) is fixed Posted Oct 28, 2010 12:24 UTC (Thu) by Curan (subscriber, #66186) [Link]
- Unstable (3.5): http://packages.qa.debian.org/i/iceweasel/news/20101028T1...
- Experimental (3.6): http://packages.qa.debian.org/i/iceweasel/news/20101028T1...
Debian (big thanks to Mike Hommey) is fixed Posted Oct 28, 2010 12:35 UTC (Thu) by i3839 (guest, #31386) [Link]
Archlinux also got updates already, thanks to Ionut Mircea Biru:
Build Date: 2010-10-27 20:56:39 UTC
|
|||||||||||||