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."

JNI is an API, not a platform...

[patniemeyer]

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.

JVM - no, that's safe. JNI is an API, not a platform. For that matter you can say that any language which uses sockets for network programming or can write a file is unsafe. Not to mention that normal programmers never use JNI... It's a very low level integration API.

Don's comments did not really add anything that wasn't covered in the Slashdot discussion.

Pat Niemeyer
Author of Learning Java, O'Reilly & Associates

Re:JNI is an API, not a platform...

[Rinikusu]

Isn't JNI basically what you use when you want to write a "java native" driver for your custom hardware (I'm thinking x10 and what not)? (But then you'd have to port the JNI to every platform you wanted to support, right?)

FUD

[micromuncher]

To use JNI inside of an applet, it needs to be signed with the DLL/shared library pre-installed in lib. 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.

Re:JNI is an API, not a platform...

[essiescreet]

Yes, this is corrrect. The jni allows you to declare "native" methods for Java. This allows you to do stuff like connect to shared memory, process UNIX signals, and do other low-level operations that are platform specific.

So, you do have to port it, but it's there if you really, really need to do something in C that you can't do in Java.

As for normal programmers not using it, that's not true. I use the JNI for integrating java with a large software package that's written in C, and runs on AIX or Linux. I'm a regular programmer. It's really not that difficult, just a little different.

In my case, it's allowed me to write Java add on's to a system that's written in C. This makes the delopment faster, the GUI's prettier, and the interface is the only C code to manage.

Re:FUD

[Anonymous Coward]

You can't use Unsafe/PInvoke inside a .Net hosted control (applet) unless permissions have been explicitly granted beforehand.

So to get outside that sandbox, you need to jump through configuration hoops.

Re:JNI is an API, not a platform...

[patniemeyer]

First, technically there's no reason you couldn't build an API allowing pure Java hardware drivers. Sun did it for JavaOS (which apparently went nowhere, but for other reasons). I wish someone would take this idea and port it to Linux, giving us pure Java device drivers.

But in answer to your question - yes, you can use JNI to talk to unsupported hardware by invoking native routines and, internally, the Java libraries use it to invoke native code on the platform for basic services like talking to the filesystem, sockets, or anything that's not written in pure Java.

Many people might be surprised though to know just how much of Java is written *in Java*... The vast majority of the APIs are pure Java code. Only the lowest level stuff is delegated to platform specific code. For example, Java does DNS and most crypto in pure Java.

And finally, most X10 hardware uses a serial API... I have one controlled by Java... also a network of Dallas Seminconductor sensor devices controlled by Java.

Pat Niemeyer
Author of Learning Java, O'Reilly & Associates

Inaccurate comparison

[shlong]

Saying that the JNI exposes Java to the same C/C++ flaws as .NET/CLR is techinically true, but not very accurate. JNI was added to Java purely to allow the JVM to operate as a browser plugin. It wasn't something that Sun really liked or wanted to do since they really wanted Java to be a better, safer, and portable language. I think that this point was even discussed in some of the early books on JNI.

Microsoft, however, is actively looking to extend the CLR with a JNI-like interface. Why? To make it easier for people to port their legacy C/C++ apps to .NET. If you can keep most of your exsiting codebase untouched and just write .NET wrappers to access it, porting is theoretically easier. Microsoft doesn't care about platform portability (or safety, for that matter), they just want an easy way to get faster adoption.

Looking back at Java, JNI calls are hardly ever used. There are few books on the topic (I think an O'Rielly book on it was supposed to come out years ago on then got mysteriously pulled), and very few Java projects use it. It's a different mindset and a different set of goals between .NET and Java, and I think that Gosling is perfectly justified in pointing out the dangers of the path the Microsoft is taking.

Re:JNI is an API, not a platform...

[YU Nicks NE Way]

Managed C++ is type and bounds safe. Unsafe C# and/or C++ allow type inference, but not bounds checking, and therefore allow a major class of exploits that aren't possible within the standard portions of the dialects. A call into C/C++ from within CLR requires PInvoke, just as a call into C/C++ from Java requires JNI.

Normal programmers writing in C#/Managed C++ use C/C++ less frequently than "normal" Java programmers do, actually, because they have access to the intermediate "unsafe" calls, through which most perf sensitive enumerations can be run without moving "down to the metal".

Basically, Gosling said it, and you fell for it. In /.-speak, they say "YHBT, YHL, HAND."

Re:What do these both have incommon?

[javatips]

Java source code is available [sun.com] with little effort. So if you want to check it out and do some security analysis, you can do it.

Inaccurate Inaccurate comparison

[steve_l]

JNI is the second edition at a Java to C++ API. It is the underpinnings of every binding from Java to platform there is, not an afterthought for applets (though Netscape were involved). If you don't use it much in your code, it's because other people (i.e Sun) do it for you. They also go out their way to make it hard to do so, whereas MS, with P/Invoke and COM support, make it really easy to invoke native code *from trusted apps*.

Most .NET code that I know doesn't use unsafe either: MS go out their way to discourage you. You have to compile as unsafe, grab pointers only briefly, and then only ever get to run if your code came from a trusted place. All remote code is blocked, even that on a network share.

Where MS do care is about COM integration, about platform integration. True, there is only one platform they care about, Windows.

But consider this: Integration between Java and Linux, especially the GUI, sucks. Want decent Java/Gnome bindings? You need the third party Java-Gnome libs, which use, wait for it, JNI. Want Java KDE bindings, go to KDEJava and get the java libraries plus native code. If you want to integrate with the OS, you need native code, which means JNI.

The fact that JNI is pretty rare can be seen by the fact that Gnome, KDE and drag-drop integration with the rest of the Linux GUI is pretty much nonexistent.

I think the FUD Sun are saying about "unsafe" is so bogus. If they want to slag it off, just pick on the .NET APIs, too much of which are thin wrappers around Win32. OR the fact that the .NET runtime needs IE6 installed, and IE6 is the web browser component for .NET apps. OR the fact that ASP.net is built on IIS. Those are security holes. Windows is a security hole. ActiveX is a gaping security hole. IIS is server side disaster. .NET is actually pretty secure, but its just damage limitation on an otherwise dangerous piece of junk. Its like having ABS brakes on a Ford Explorer; not enough on its own to stop you crashing and burning horribly.

Re:JNI is an API, not a platform...

[MoebiusStreet]

The vast majority of the APIs are pure Java code.

RTFA:

In looking at the Indigo code base (which was 1123 C# files as of early last week), only 19 of them use the unsafe keyword.

Why in the world would one consider the *possibility* of unsafe code in the CLR a security hole? Sure, you can call the use of unsafe a hole. But if (like virtually all .Net developers I know) you never use that, then there's no issue at all.

Is Gosling complaining that the CLR is so flexible that someone with extraordinary needs *can* use unsafe when necessary?

Re:C++ support in Java vs .NET

[mibus]

And too bad if you're running Mono on a non-x86, non-Linux system since winelib is x86 only (for now).

From the Darwine FAQ [opendarwin.org]:
It means that WineLib is now working on Mac OS X, and that developers should be able to recompile their Win32 Apps using WineLib and make them work in Mac OS X.

Re:JNI is an API, not a platform...

[JesseT]

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.

You got this wrong too. As Don explained in his blog, if you weren't too busy to have read it, you'd realize that "unsafe" C# is still managed code. It doesn't get "linked" through the CLR's equivalent of a JNI interface. It's still managed code. There isn't any unmanaged code here to speak of. C# code can still interoperate with unmanaged code using the .NET BCL's P/Invoke and COM interop layers, but it has nothing to do with the "unsafe" subset of the C# language. It's a part of the .NET Framework itself, and all managed languages targetting the .NET Framework can utilize those features.

Re:JNI is an API, not a platform...

[bigsteve@dstc]

Either way, it's unsafe.

If the JVM and (say) C code are in separate address spaces, then the C code does not ever need to see the physical addresses of Java objects, or anything else in the JVM address space. Thus, the JNI API can in theory be implemented so as to make it impossible for the C code to break the Java type system.

However, I've never come across a JNI API implementation that works that way. It is just too expensive.