Comparing Java and .NET Security


It’s been a while since I’ve last seen a comparison of Java and .NET securityNathaneal Paul and David Evans from the University of Virginia Computer Science Department recently finished their comparison, Comparing Java and .NET Security: Lessons Learned and Missed.


In their paper, Nathaneal and David take a bottom up approach to examining the security models of each platform.  They start with the opcodes that make up the instruction set of each virtual machine, and examine them both from an instruction set design perspective as well as from a verification perspective.  They use the SSCLI to compare verifier implementations between the CLR and Java.  From there, they look at the way each platform allows for policy creation and the permissions that each uses.  The paper ends with an examination of how each platform uses its policy system, from bootstraping to modifying the stack walk.


At the beginning of the paper, Nathaneal and David compare the number of reported major security vulnerabilities in the Java VM and the CLR since each had their official 1.0 release in January 1996 and January 2002 respectively.  Their data makes for an interesting graph, presented in their paper as Figure 1:


Java vs CLR major security vulnerabilities

Comments (12)

  1. Confused says:

    In the real world, Java security matters most for applets in a browser or "sandboxed" applications, e.g. when I don’t want a website trashing my hard drive.

    Please explain when security matters for .NET. This is something that has always eluded me. The standard Windows application model is to download and run code without any security restrictions, so why do I care if an application I downloaded in .NET runs in a sandbox? The time it matters is when websites start embedding .NET applets. I’ve never seen one other than sample code.

  2. Mr E. says:

    This would mean more, if .NET had not in fact any benefits from java. If .NET had come first, how would it be then?

  3. Murali says:

    In the real world, security is not limited to web pages or applets. Web applications are only of a very little portion. Anyways, java Applets never gained ground at all in any non-trivial, non-demo applications.

    It does not matter who comes first, java or .net. When java arrived, it also LIFTED the best concepts available then. And no wonder any new language/platform that comes up will be better than the current.

  4. Keith Farmer says:

    Murali: And thus is has always been.

    Got a problem you see with a language — write a new one. No harm in it, and as we’ve learned, some tangible benefits.

    Confused: It doesn’t matter *where* it’s most useful at the moment, since vulnerabilities arise from code being developed with invalid or short-sighted assumptions. .NET’s security model allows us to make sure security runs very deep throughout the system, no matter where the code is run. Let’s be honest, code that sits entirely within the host machine is losing ground.

  5. Still Confused says:

    kfarmer: Java applets are in production use by millions of people every day from rich online stock trading applications to yahoo games.

    This report is a sham. No one has found security bugs in dotnet because there is no incentive to do so. If I’ve been able to get you to run my malicious .NET code, I could have just as well gotten you to run a native app. With java, malicious attackers can break into web clients if they find a hole, so there is a payoff.

  6. Tom says:

    TO Mr. CONFUSED:

    So you claim it’s OK that Java has vulnerabilities because it’s run in the sandbox (thus it’s justified), while it’s not OK that .NET has not vulnerabilities because it’s not run in the sandbox? Am I right?

  7. Not Confused says:

    My claim is that the number of so far discovered security bugs in CLR is no indication of the relative security of the CLR versus the JVM. A hole in the Java sandbox is as bad as a hole in IE, whereas there is no analogous threat for the CLR.

  8. Ecco un interessante relazione, proveniente dal mondo universitario, che svolge un’analisi sulla sicurezza…

  9. Tom says:

    That means CLR is safer than JWM, doesn’t it?

  10. Rob M says:

    1) Graphing any comparison of zero vs anything greater than zero is bad.

    2) Using the cumulative bugs makes it look worse becuase visually you see an ever increasing (getting worse) graph. Bugs per year would be better, broken down my area, or serverity would be nice too.

    3) A comparison plot of how many machines running each VM at the time, how many applications, etc would be a good reference. Does .net have no security violations because its rock solid or because no one cares yet?

    I haven’t read the rest of the article yet, but it does not appear that the authors are being that objective about their hypothesis.

  11. hisashi says:

    As a mobile code platform, I think that Java applets have some serious problems in design. See details:

    <a href="http://www.acsac.org/2004/abstracts/62.html">Cozilet: Transparent Encapsulation to Prevent Abuse of Trusted Applets</a>

    I am not familiar with .NET, does any similar problem exist?

  12. Chris says:

    Hey,

    Did anyone actually check the bugs listed in the report. Here are the ones under the first 3 headings.

    This security report is intended to be completely misleading.

    CVE-2000-0711 – Netscape Communicator and Navigator 4.04 through 4.74 allows remote attackers to read arbitrary files by using a Java applet to open a connection to a URL using the "file", "http", "https", and "ftp" protocols, as demonstrated by Brown Orifice.

    CVE-2000-0711 – Netscape Communicator does not properly prevent a ServerSocket object from being created by untrusted entities, which allows remote attackers to create a server on the victim’s system via a malicious applet, as demonstrated by Brown Orifice.

    CAN-2000-0563 – The URLConnection function in MacOS Runtime Java (MRJ) 2.1 and earlier

    and the Microsoft virtual machine (VM) for MacOS allows a malicious

    web site operator to connect to arbitrary hosts using a HTTP

    redirection, in violation of the Java security model.

    CVE-2002-0865 – A certain class that supports XML (Extensible Markup Language) in Microsoft Virtual Machine (VM) 5.0.3805 and earlier, probably com.ms.osp.ospmrshl, exposes certain unsafe methods, which allows remote attackers to execute unsafe code via a Java applet, aka "Inappropriate Methods Exposed in XML Support Classes."

    CVE-2002-0866 – Java Database Connectivity (JDBC) classes in Microsoft Virtual Machine (VM) up to and including 5.0.3805 allow remote attackers to load and execute DLLs (dynamic link libraries) via a Java applet that calls the constructor for com.ms.jdbc.odbc.JdbcOdbc with the desired DLL terminated by a null string, aka "DLL Execution via JDBC Classes."

    CAN-2002-1290 – The Microsoft Java implementation,as used in Internet Explorer,allows remote attackers to read and modify the contents of the Clipboard via an applet that accesses the (1) ClipBoardGetText and (2) ClipBoardSetText methods of the INativeServices class.

    CAN-2002-1288 – The Microsoft Java implementation,as used in Internet Explorer,allows remote attackers to determine the current directory of the Internet Explorer process via the getAbsolutePath() method in a File() call.

    CAN-2002-0979 – The Java logging feature for the Java Virtual Machine in Internet Explorer writes output from functions such as System.out.println to a known pathname, which can be used to execute arbitrary code.

    CVE-1999-0141 – Java Bytecode Verifier allows malicious applets to execute arbitrary commands as the user of the applet.

    CVE-1999-0440 – The byte code verifier component of the Java Virtual Machine (JVM) allows remote execution through malicious web pages. . JDK 1.1.x

    CVE-2000-0327 – Microsoft Virtual Machine (VM) allows remote attackers to escape the Java sandbox and execute commands via an applet containing an illegal cast operation, aka the "Virtual Machine Verifier" vulnerability.

    CVE-2002-0076 – Java Runtime Environment (JRE) Bytecode Verifier allows remote attackers to escape the Java sandbox and execute commands via an applet containing an illegal cast operation, as seen in (1) Microsoft VM build 3802 and earlier as used in Internet Explorer 4.x and 5.x, (2) Netscape 6.2.1 and earlier, and possibly other implementations that use vulnerable versions of SDK or JDK, aka a variant of the "Virtual Machine Verifier" vulnerability.

    CVE-2003-0111 – The ByteCode Verifier component of Microsoft Virtual Machine (VM) build 5.0.3809 and earlier, as used in Windows and Internet Explorer, allows remote attackers to bypass security checks and execute arbitrary code via a malicious Java applet, aka "Flaw in Microsoft VM Could Enable System Compromise."

    CVE-2002-1287 – Stack-based buffer overflow in the Microsoft Java implementation, as used in Internet Explorer, allows remote attackers to cause a denial of service via a long class name through (1) Class.forName or (2) ClassLoader.loadClass.

    CAN-2004-0723 – It has been reported that applets running in the Microsoft JVM share a common data structure that can be both written to and read from by any applet, regardless of domain association. This is in violation of the above security policy.