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."
Are we just going to have this continuing debate in which every side is inaccurately reduced to one slashdot-blurb-sized sound bite?
Anyway, JNI doesn't need to be a security hole of the sort Mr. Box mentions; one can concieve of a Java VM which disallows unsafe JNI code from touching the memory of the bytecode-verified safe code, by partitioning JNI execution into a separate process. In fact at least one such JVM implementation exists already.
For that matter you can say that any language which uses sockets for network programming or can write a file is unsafe.
.NET CLR allows you to tweak that out and explicitly deny those rights. (By default these rights are denied for applications running on a remote store.)
And, as Don Box said, the unsafe keyword is not meant for daily consumption. To paraphrase, "normal programmers never use the unsafe keyword. It's a very low level integration API."
Actually, yes that is a true statement which is why the
And a similar blog entry here:
/ 07 /368226.aspx
.NET has a huge security hole. The problem seems to be that .NET allows execution of both safe and unsafe managed code in the same process:
.NET defines, and this sort of code requires additional permissions to execute. According to Sterling, "you as a developer take it upon yourself" to utilise unsafe code in your .NET applications.
:-)
http://blogs.msdn.com/adioltean/archive/2005/02
I am reading now an article in which James Gosling claims that
[...], Gosling is concerned about "unsafe" code, which is produced by traditional languages like C and C++. Unsafe code is old code that does not strictly follow the rules of type safety that
But what James Gosling fails to mention is that the Java runtime also allows the same type of unsafe code execution in every process running safe Java code. No, I'm not smoking crack. The technology is well established in the Java world and it is called JNI. Here is a quote:
The JNI allows Java code that runs within a Java Virtual Machine (VM) to operate with applications and libraries written in other languages, such as C, C++, and assembly. In addition, the Invocation API allows you to embed the Java Virtual Machine into your native applications.
Programmers use the JNI to write native methods to handle those situations when an application cannot be written entirely in the Java programming language. For example, you may need to use native methods and the JNI in the following situations:
The standard Java class library may not support the platform-dependent features needed by your application.
You may already have a library or application written in another programming language and you wish to make it accessible to Java applications.
You may want to implement a small portion of time-critical code in a lower-level programming language, such as assembly, and then have your Java application call these functions.
Think of it a second - in fact, how does a small Java program interoperate with the underlying operating system? How does a "Hello world" Java program succeed to write anything to the console? After all, the Win32 API is not directly callable from Java, correct?
Therefore, by its own measure, Gosling only suceeded to demonstrate that Java also contains a huge security hole...
P.S. And, please, don't tell me that JNI is not a security hole because writing JNI code is eventually harder and not done as often than using "unsafe" in C#... 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...
Don't try to use the force. Do or do not, there is no try.
In any case, that's not why IIS is a target. IIS is a target for a number of reasons:
1. The default web server (once you installed the Option pack) on NT4 was a version of IIS that had a couple of security holes.
2. IIS is almost certainly more popular than Apache on Windows-type servers. Yes, Apache runs on it too, but there's a mentality that goes with Microsoft products. With Windows being the most "popular" (well, most installed) operating system in existance, you'd expect it to be the home for most virus writers, and virus writers aren't going to want to write for platforms they consider obscure.
3. IIS always runs on Windows which almost always has the same CPU architecture (ie ix86) and APIs. Apache can run on a variety of platforms. Exploiting, for example, buffer overflows, is relatively difficult if you don't know the architecture, or even something as simple as how you can make system calls.
4. People hate Microsoft. Most people's views of Apache and similar systems are neutral at worst. I've never met or talked to anyone who hates Apache.
5. One serious hole is enough. Both Apache and IIS have suffered these in the past and probably will do in future (well, until Gosling rewrites Apache in Java ;-)
IIS is usually used as the proof to counter the argument that marketshare matters when viruses are written. I think this is always a bogus argument: IIS's marketshare is enough (it's not like writing a virus for GNU/Linux), and IIS is tied to an operating system that is the most installed in the world. It's fair to say it's the exception that, quite literally, proves the rule.
You are not alone. This is not normal. None of this is normal.
I write a lot of C#, and I almost never use unmanaged code.
But sometimes I do. I would start far fewer projects with C# if I couldn't be sure I could get out of that particular straightjacket.
That being said, I am starting to have my doubts about writing huge programs without giving a thought to memory management. It is fun, and it is fast, but there is no way back...
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.
.NET doesn't afford?
.NET developers use Interop to access lower level APIs and interfaces.
.NET gives you only the worst of both worlds. .NET; security is a holistic effort. Your sysadmin needs to disable access to dangerous operations; the developer needs to put in place security measures (regardless of what language); the user needs to know how to operate software.
.NET has this also. Try running an assembly off a remote store or even run a method through a remote channel. .NET's standard security is pretty high. It respects system permissions and principals, so I'm not sure why people keep saying it's some sort of apocolyptic risk.
Which I'm guessing your misinformation leads you to believe that
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.
Right...for "hot code"
As far as I can tell, by allowing unmanaged code in the runtime,
I'm not really sure why you're wailing on
JNI does essentially the same thing as Interop. People who have been using JNI in its originally intended context don't see this, but some people use JNI to access lower level interfaces and APIs (such as shared memory, native APIs, etc.).
Now, of course, I'm sure you'll gloat about the proverbial "sandbox" that Java offers, but you fail to realize that
Unmanaged isn't any different than writing a program and using JNI to talk to it.
[ check out my ruby book @ http://ww
And that's why a whole class of software is not written in Java. Get out of your web services, connect to database world.
At my previous position, we had a volume renderer that was written in C++, an SDK on top of the volume renderer that was written in managed C++, and applications were written in C#, VB.NET and Python.NET.
The right tool for the right job.
Using JNI would have been a pain in the eff-ing ass. Java is not low-level enough to be a high-performance systems programming language, and not high-level enough to be a scripting langauge. Hence, a good choice for web services but not the best choice for anything else.
Let's take a look at how each technology can become a security hole: By remote execution of content presumed to be in a "sandbox".
.NET: Since unmanaged code is turned off by default for remotely loaded code, it will not be run by an unexpected trip to a web page.
.NET is sophisticated enough to allow some apps to use unmange code, but not others, or some users, or software from a certain publisher, and a bunch of other options as well. You don't have to simply "turn on unmanaged code". They even have a simply way to allow software publishers to communicate these settings to customers instead of letting Joe Blow admin decide to simply turn off security to make it work.
Java: Since JNI won't work by default under the same circumstances, the newest virus won't be injected into your system by an evil web page.
Anything else is simply an architectural choice. MS likes to preserve compatibility while allowing you to move forward as quickly as posible. Sun wants you to rewite stuff in Java (for the most part), so the new stuff is more secure, but there will be more old stuff floating around that is still unsecure because we won't yet have found time to port it.
BTW, Code Access Security in
In summary, both technologies allow you to blow your own foot off if you aim the gun properly and squeeze the trigger. So what -- we were allowed to do that before these technologies came along and preventing you from being able to blow your own foot off will only slow adoption and cause more feet to be blown off.
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 .NET have so far succeeded server side.
Why bother with tainting when you can just do rigorous validation with things like struts? It's been quite a while since I've seen a bug related to inappropriate input handling, and that was in a perl script.
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.
It's actually rather hard to fall victim to a SQL injection attack unless you are just using the APIs the wrong way (which is more difficult). In our application...I can only think of a couple of places where SQL is generated in the code, and in those places, we generate prepared statements to deal with any input.
-- The world is watching America, and America is watching TV.
5. One serious hole is enough. Both Apache and IIS have suffered these in the past and probably will do in future (well, until Gosling rewrites Apache in Java ;-)
When you see the first Apache-based worm which has 15 different potential attack vectors-- which nimda did-- you may make this argument. Not until then. Yes, one vulnerability may be all you need. But the others, ah, certainly help, especially considering that the more critical vulnerabilities are out there, the less likely all extant installations have patched them all.
I also find it very wierd that you try to use both "virus writers use microsoft products" and "virus writers hate microsoft" as excuses for IIS's worm problem. Wouldn't there be a slight problem with those two overlapping?
Aside from this, believe it or not, worms are not the only thing out there which make use of security exploits, and the other things don't fall prey to the situations you describe. IIS's poor security track record did not begin with the worm problem. the worm problem just threw it into such sharp relief it could no longer be ignored.
"See, it's XML over HTTP, so no need to change your firewall configuration". Security? Ah!
And Microsoft bought into it because they needed something to interoperate with the rest of the world, and they couldn't do a 180 and use CORBA without "looking bad".
And now we get that XOP turd (discussed here [slashdot.org]), because somebody wisened up and realized that XML was just bad at byte framing, and, yes, we need binary data.
JNI is an absolutely necessary part of Java. How do you think System.out.println() really works? Down through the (many) layers of calls within standard Java classes, you eventually get to a JNI call. In fact, without JNI, Java wouldn't be able to access the network, files, console, etc. It's like saying the keyboard is responsible when you type format c: (or when you click-click-click for the younger generation).
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
The consequence of this is that no-one uses JNI unless they absolutely positively have to. It's a pain and life is much easier if everything is in Java. Thus with the exception of a few esoteric things such as SWT, most libraries are pure and portable.
Now contrast this with .NET. Writing native C++ and wrapping it in a garbage collection safe class involves no stub generation and can be done in a single file - the assembly info, interface and gc wrapper can all be specified in situ. Consequently it's a lot easier to pull C++ into a .NET application. MS DevStudio 2003 even has wizards to do it. It is also a lot easier to call DLLs and ActiveX from .NET since MS provide PInvoke and COM Interop to do just that.
Now on the face of it, this is all well and good, especially if you have a lot of legacy crap to port. But by the same token it means many more .NET apps are tainted than on Java. The problems this causes for portability should be obvious.
And this is called "Microsoft having their cake and eating it". They can expound portability and present the facade that .NET is cross-platform, when in reality they provide tools and wizards to ensure it remains anything but. Apps that are infested with native instructions and OS-specific calls are by definition unportable.
Mono demonstrates the problems faced in porting .NET to other platforms. Mono must literally pull in the whole winelib in order to cope with the number of tainted .NET apps that attempt to call out to Win32. And too bad if you're running Mono on a non-x86, non-Linux system since winelib is x86 only (for now).
And I don't see the situation getting any better. Perhaps if Mono gains momentum it might put the brakes on tainted code, but there is a long way for that to happen. I believe the only way Mono is going to make an impact is if ships with a cross-platform IDE with tools that default to its open source stack. This is almost a reality since ICSharpDevelop & MonoDevelop are both fairly complete IDEs but there is nothing yet which defaults to the open source stack and runs on all major platforms.
Who says that JNI code is run in the same address space as the JVM? That's an assumption you are making because you miss the point entirely that JNI is an API. The C code could be running in a separate process using IPC to transfer the data (you don't access Java memory directly when using JNI) for all you know.
For that matter, the JVM could be integrated into the kernel where all Java (and thus safe) code is run in a single address space and the C code could be run in a restricted address space using the MMU to enforce the code, thereby getting better performance by not needing bounds check or whatever. The point is that C# is insecure because of taking Java's design and hacking it up without understanding why it was designed that way. Incidentally, that applies to their hacked up Java standard library as well as at the VM level.
I understand your point, but I believe that there is potential for many more exploits in Java than you let on. For instance, here's the .so file for the AWT shared libraries on my 1.4.2 JDK:
/usr/local/java/jre/lib/i386/libawt.so
3059052 Jun 4 2004
That's 3MB (w/o debug info) of potentially exploitable wrapper code, lots of which depends on complex and (and potentially exploitable) Win32/X/Motif/whatever code. The rest of the shared libs total to about 6MB. Java's native layer is not thin like say, Smalltalk -- part of the reason for this is performance, part is feature set.
Also, a quick search for "buffer overflow" on the Java bug database brings up 1860 results. I'm sure one or two of those involve native code and were/are potentially exploitable, just no one got around to it.
Yes, I'm sure much of the Java codebase is heavily audited, and the common things like socket/file I/O are pretty secure. But I wouldn't say "all is well" if I had to bet my business on that being true.
A typesafe language is no replacement for secure programming knowledge, several vendors offer classes in that realm:
n g_Training.htm
http://www.liveammo.com/LiveAmmo_Secure_Programmi
and
http://www.cerias.purdue.edu/secprog
---------- http://www.LiveAmmo.com
The original argument Gosling had was how easy it was to produce something "unsafe" from legacy code.
.NET is a serious desktop platform. Desktop applications are trusted, and hence there is no problem with them running legacy code in a trusted mode. Lack of a good migration path from legacy code to Java is one of the big problems with Java.
.NET enforces the same sandboxing and trust model as Java when it comes to applets and remote code, so there are no security problems arising from the ease with which you can migrate code to it.
.NET because I don't want to tie myself to Microsoft platforms. But Java, at this point, is technologically and legally such a disaster that it is not a reasonable choice for most applications. Java deserves every bashing it gets, from M$ as well as from long-time Java users like me.
No, Gosling wasn't complaining about lack of safety, he was complaining about lack of security. He keeps confusing the two issues, and you apparently do too.
There is nothing wrong with producing something either unsafe or unsecure from legacy code: unlike Java,
On the other hand,
because it's just fuel for the m$ minions to go Java bashing.
Gosling started this, Box responded. Box's response was entirely accurate and appropriate.
As for "m$ minions", I am not using