| |||||||||||||
Surprisingly enough...Surprisingly enough...Posted Oct 28, 2010 20:53 UTC (Thu) by mikov (subscriber, #33179)In reply to: Surprisingly enough... by alankila Parent article: A Firefox zero-day vulnerability
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.
(Log in to post comments)
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.
|
|||||||||||||