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."
Solaris - yes, it's unsafe. That's why my Solaris machine gets attacked if I don't have a firewall in front of it for ten seconds.
Really? Who the hell writes worms for such an obscure platform?
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!
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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
You make some good points. Nobody does use unmanaged BTW, its just too painful. There is one thing wore than it: managed C++.
.NET have any notion of tainted data. all this security stuff does is let you run untrusted code in a sandbox, or trusted code in a secured zone to slightly limit the damage it can do.
.NET have so far succeeded server side.
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.
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.
To use JNI inside of an applet, it needs to be signed with the DLL/shared library pre-installed in lib.
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.
Some people just have to do low-level stuff in a high-level application. People can write malicious code for that, but that's the price you pay.
.NET does a lot to reduce the amount of old-fashioned pointers you need. Most of that has been wrapped up into things like references and delegates, which can be tracked and managed.
.NET framework, but I think that would have reduced a huge selling point. .NET is more than just a VM, and it's trying to solve a lot of problems. C++ should be able to take advantage of it.
.NET will become the next overwhelming thing, and it's VM will be widely adopted--hence the biggest target for attacks. It's very possible to write a JNI exploit that the naive user may also run. Ultimately, accountability still resides with the end user, but these higher-level languages have reduced the amount of stuff the end user has to track.
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
No I'm not trolling.
Or rather, Gosling was pointing out an inherent advantage of Java that was one of the primary design goals of Java, but which .NET does not concern itself with. Then Don Box said he doesn't think it's an advantage. Then you agreed that you don't think it's an advantage.
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.
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.