Don Box: Huge Security Holes in Solaris, JVM 226
DaHat writes "Don Box, one of the authors of the original SOAP specification in 1998, now an architect on Microsoft's next generation Indigo platform recently responded to James Gosling's remarks regarding huge security holes within the .NET Common Language Runtime (CLR). Don argues that the same 'flaws' that Gosling noted in the .NET CLR exist both within the Solaris operating system as well as the JVM, both of which support execution of C and C++ code, as well as explaining why this is not necessarily a bad thing."
Re:JNI is an API, not a platform... (Score:1, Insightful)
Really? Who the hell writes worms for such an obscure platform?
Yawn! (Score:2, Insightful)
Programs will have bugs, regardless of what programming language that is used, since it always comes down to machine-code or even microcode in the end, and it's not easy to test a large software package for all possible permutations.
The only way around this problem is a layered security approach, which means that breaking one layer will not cause any critical effects. Unfortunately Microsoft has only recently recognized this and are applying patches on and off. Solaris and most *NIX:es are a little better off, but there are a lot of work to do for all operating systems here!
Why "managed" == "denial" (Score:5, Insightful)
There is great value in a "managed" system like the Java VM. It gives us an extraordinary amount of safety that we are frankly unaccustomed to. People are still gradually learning how to think about it, but you see more and more security-critical projects going "Java only" as they figure it out.
There is also obviously no way we can do everything that way. For hot code, we work at lower levels, put in more work, and (for now) accept the additional risks. Note that the constant stream of ugly worldwide security problems is gradually but now noticeably decreasing our apetite for doing everything that way.
As far as I can tell, by allowing unmanaged code in the runtime,
You get all the overhead of the VM, but you don't really get safety.
I know perfectly well you can tell the
Either it is avoided by everyone (everyone recognizes that it's a mistake), or we all begin to use it (it's in XYZ library), and then we all end up allowing unmanaged code, and we are no longer safe.
Re:JNI is an API, not a platform... (Score:4, Insightful)
Of course... and Java executes RISC instructions that could reveal flaws in the processor design too... but those levels were not written in the course of daily programming. The native drivers in Java are very small (e.g. all of Swing is built on a few AWT calls for opening windows and doing primitive drawing). And those routines presumably get a lot of scrutiny for all kinds of reasons - security being one and performance being another. I have never heard of a common security problem like a buffer overflow in the native libs shipped with Java... It's going to happen someday of course and that's why people created Java and managed code. To minimize the exposure of those regions.
The futher up the food chain your code goes the more protected it is and the harder it becomes to exploit low level security holes. It's analogous to the way in which you (used to?) gain confidence in the GNU C compiler by having it compile itself and then using the 2nd gen to compile a third... At each step the possibility of simple problems become much more abstract and harder to exploit.
Pat Niemeyer
Author of Learning Java, O'Reilly & Associates
Why no tainted data in either runtime? (Score:3, Insightful)
One thing though, neither Java or
But neither language has the idea of marking strings or other data that came from an untrusted source, the way Perl does. Which is odd, as both Java and
Compared to Perl, Java is insecure as you can too easily fall to a SQL string attack, either in your web page, or, heaven forbid, Web Service.
Re:JNI is an API, not a platform... (Score:4, Insightful)
You can look at C# as two languages: an "unsafe" and a "safe" language. The safe language is the equivalent of Java. The "unsafe" language is the equivalent of C or C++ linked in through JNI. Linking "unsafe" to "safe" code in C# has the same restrictions on it as does linking native code to pure Java code in Java. So, Gosling's rantings have no technical merit.
However, the C# solution is better than the Java solution: unsafe code in C# still contains substantially more error checking than equivalent C code linked through JNI, you generally need much less unsafe code in C# than in Java to accomplish the same task, and C# unsafe code doesn't need to be recompiled for different platforms and can just be distributed like other C# code.
Don's comments did not really add anything that wasn't covered in the Slashdot discussion.
What do you want? He is responding to an enormously stupid, self-serving comment from Gosling. You have to be clear and keep things simple in order to reach the kind of people who would swallow Gosling's nonsense in the first place.
the FUD comes from Gosling (Score:2, Insightful)
And the equivalent is true for C# "unsafe" code: there are restrictions on where it can be run from and what can run it.
So, the topic of "Huge Security Hole in Solaris and JVM" is alarmist and FUD, considering that to get outside of the sandbox, you need to jump through serious configuration hoops.
The FUD is the nonsense Gosling was spewing about C#. Box is responding with hyperbole (he says so explicitly) to demonstrate how absurd Gosling's argument is.
Unfortunately, creating FUD seems to be a major occupation at Sun these days, and the targets are Sun's biggest competitors: Microsoft and Linux.
I don't see the big fuss (Score:2, Insightful)
The little bit of C# I've looked at has shown that
They could have also prevented C++ from coexisting with the
I think people are just complaining is on the assumption that
Re:Why "managed" == "denial" (Score:3, Insightful)
Relax.
Try running an assembly off a remote store or even run a method through a remote channel.
I'm aware that the default security configuration in
I don't want to confuse "attack" with "mistake." What about problems in local unmanaged code that we wrote ourselves?
Unmanaged isn't any different than writing a program and using JNI to talk to it.
I don't know how good a comparison this is.
Any VM must use "managed" code to interface with lower-level "unmanaged" code. This is what you see in any core library: wrapper objects that invoke unmanaged native code. No PC is "managed" down to the silicon - although some Java embedded devices literally are.
The difference is in how that boundary works. In Java, JNI is deliberately very rudimentary and extremely low level. It is designed exclusively to allow access to native routines - not bit twiddling within the VM itself. It's use is vehemently discouraged by policy (100% pure etc etc) and JNI use in the field is rare as a result.
Everyone can hammer on the fixed Java API, and at some point we trust that lower-level foundation. We then declare that our own Java code, built on top of it, is "safe" and "managed."
In
http://msdn.microsoft.com/library/default.asp?u
They encourage the use of unmanaged code, and the framework makes it much, much easier to use. It's billed as a feature.
We slip in unmanaged C# to fiddle with buffers to do parsing or whatever. This is not going to C like in JNI, but just quick-and-dirty cheating within the VM. There is no such thing as "unmanaged Java."
So you can cheat the VM and make C# a little faster. But now no one is looking over your shoulder. Your new unmanaged code may have problems. You are not safe in your VM anymore (nor are you portable). Meanwhile you still have the overhead of running that way.
It often comes up in the Java community that people wish JNI did more work for you, so that it would be easier to use. But we always come back to the same answer: if you make JNI easy, and start encouraging its use (going the Microsoft route), soon everyone is using it. There is no more portability and you lose security and stability. Great for MS, of course. But if we really don't care about that, why not just back away from the VM in a more orderly fashion altogether?
Re:JNI is an API, not a platform... (Score:1, Insightful)
You got it wrong. Box fully agrees that the design goal is quite important. He just points out that Java achieves it no more than C#.
But that doesn't make the advantage go away. It just means that neither you, nor Don Box, are interested in it.
There is no "advantage" to go away; if there is any difference at all, it is that JNI code is both more likely to contain serious errors and that it is far less efficient invoking it.
Re:JNI is an API, not a platform... (Score:4, Insightful)
Many of the classics, among them Lisp, Algol, APL, Simula, and Smalltalk. Modula-3 even had C#-like safe/unsafe sublanguages (as did a few other languages). And while they didn't have GC, languages like Pascal and Modula were safe languages in most other respects.
and is the greater safety not in large part due to the relative simplicity of older systems? I mean, how hard is it to wring all the bugs out of an application or OS written for a machine with 16K of RAM
The world did not begin with 16k Apple II's or the teenage dabblings of some industry luminaries in software. People had large computers running multiuser operating systems and safe, high-level languages in the 1960's.
and did they really bother to weed out all possible "exploits" when weren't 10,000 russian teenagers writing viruses to "zombie box" that machine?
We are talking about runtime safety here. You are confusing runtime safety and security; runtime safety helps with security, but it is neither necessary nor sufficient to guarantee it.