Gosling: Huge security hole in… Java?


I am reading now an article in which James Gosling claims that .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:

[…], 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 .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.

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…

 

Comments (8)

  1. Anonymous says:

    I want to hear an "I’m sorry" from Gosling.

    The comments on the article page say it best. All I can do is sigh, and move on to better things.

    Thanks for the article; at least making us aware of the lack of understanding on the management level.

  2. Anonymous says:

    What truly bothers me is that someone like Gosling either doesn’t know about how .NET works, which doesn’t make him the fittest person to display such opinions (and it’s also a bit lame, at his level you would expect him to know at least the basics about his main competitor) or he deliberatly ignores how the CLR actually works and the above mentioned fact that JVMs work the same way. Which kind of brings back the same old story about Sun: Good engineering, lame marketing and evangelism.

  3. Anonymous says:

    What truly bothers me is that someone like Gosling either doesn’t know about how .NET works, which doesn’t make him the fittest person to display such opinions (and it’s also a bit lame, at his level you would expect him to know at least the basics about his main competitor) or he deliberatly ignores how the CLR actually works and the above mentioned fact that JVMs work the same way. Which kind of brings back the same old story about Sun: Good engineering, lame marketing and evangelism.

  4. Anonymous says:

    No, I’m not smoking crack. The

    > technology is well established in the

    > Java world and it is called JNI.

    FWIW, you need a signed applet to call native code from Java.

    > How does a "Hello world" Java

    > program succeed to write anything

    > to the console?

    ? If you’re trying to say System.out.println makes a C/C++ stdio call to print to the console, sure. But you’re not talking about JNI, you’re talking about the Java API.

  5. Anonymous says:

    Mr. Coward,

    You need to have the right Code Access Security to make P/Invoke calls in .NET, too. In fact, I think .NET is even more secure in this regard. Just because you have signed an assembly does not mean you can run it off the web and have it call unmanaged code. Someone has to grant that permission to assemblies signed with the key in question.

    Also, I think Adi’s point was that eventually most API calls end up calling some unmanaged code, both in the java world and the .NET world. System.console.writeln is exactly the same as System.Console.WriteLine, in this respect. If this is what Gosling was referring to, then he is slapping his own face.

  6. Anonymous says:

    >> FWIW, you need a signed applet to call native code from Java.

    I know – and that makes sense. Note that in the .NET world you have similar restrictions. First, the C# compiler won’t even compile unsafe code, unless you add the "/unsafe" command-line option. Second, an unsafe assembly can be loaded by the runtime only if the parent assembly grants it the SecurityPermission access permission (which is not granted by default to mobile code – the closest equivalent of Java applets executed in a browser).

    See this link for more details:

    http://msdn.microsoft.com/library/en-us/cpguide/html/cpconcodeaccesssecurity.asp