Slashdot Mirror
Don Box: Huge Security Holes in Solaris, JVM
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."
When .NET was first announced and the details began to be known, there were a number of lively discussions here about it. The "feature" of running unmanaged code was hotly debated, but the debate seemed to me to be entirely one-sided. It seemed clear unmanaged code is another classic Microsoft mistake - trading sugary convenience today for billions in headaches for their customers tomorrow. I went looking for someone to convince me otherwise and didn't succeed. Maybe now?
.NET gives you only the worst of both worlds.
.NET runtime not to allow unmanaged code. That doesn't matter, because the choice is there, "unmanaged" is still a huge problem.
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.
Tired of Political Trolls? Opt Out!
Face it - in Java, whenever you are writing to a file, communicating through a network interface or just handling GUI controls, there is always some unmanaged C++ code being executed in your process...
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
JVM - no, that's safe. JNI is an API, not a platform.
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.
which high level languages were these, and is the greater safety not in large part due to the relative simplicity of older systems
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.