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
- Anonymous
February 06, 2005
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. - Anonymous
February 06, 2005
The comment has been removed - Anonymous
February 06, 2005
The comment has been removed - Anonymous
February 07, 2005
The comment has been removed - Anonymous
February 07, 2005
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. - Anonymous
February 07, 2005
The comment has been removed