| |||||||||||||
Surprisingly enough...Surprisingly enough...Posted Oct 31, 2010 1:40 UTC (Sun) by mikov (subscriber, #33179)In reply to: Surprisingly enough... by khim Parent article: A Firefox zero-day vulnerability
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.
(Log in to post comments)
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.
|
|||||||||||||