Comparison of Java and .NET security

prostoalex writes "The Computer Science Department at the University of Virginia has published a comparative study of security in Java and .NET in Portable Document Format. DevMktg blog on MSDN summarizes the findings saying that due to careful design process, .NET presents security advantages over Java platform in several areas." From the article: "Where Java evolved from an initial platform with limited security capabilities, .NET incorporated more security capability into its original design. With age and new features, much of the legacy code of Java still remains for backwards compatibility including the possibility of a null SecurityManager, and the absolute trust of classes on the bootclasspath. Hence, in several areas .NET has security advantages over Java because of its simpler and cleaner design."

Comments

PDF text

[Anonymous Coward]

Text conversion of PDF document

Re:Source code access

[Johnno74]

Most of the source code for .Net is available here - Its called "rotor" and is Microsoft's open source implementation of .Net. It doesn't cover the complete framework, but it includes the runtime, C# compiler, and the parts of the framework that were submitted to ECMA.

Anyone is free to download, modify and distribute rotor, it compiles on OSX and BSD. I believe someone has modified it to compile and run on Linux. Unfortunately the license prohibits commercial use...

The major differences between Rotor and the full framework are a simplified garbage collector, and a simplified JIT compiler. Microsoft aren't saying how much of the framework code is shared between Rotor and the full version, but I've been told by people with access to the source that the answer is "pretty much all of it"

Open source java security projects

[iksrazal_br]

I think this article overlooks the fact that many 'free as in speech' third party security libraries and frameworks are available for java.

1) ACEGI - Aspect-orientaded-programming using a dependency injection model to replace or complement JAAS for authentication and authorization in an Application server independant way. A subproject of the Spring framework:

http://acegisecurity.sourceforge.net/docbook/acegi .html/

2) XML Encryption and XML Digital Signatures. Used in Web Service security or independently.

http://xml.apache.org/security/

http://ws.apache.org/wss4j/

3) Container managed security implemented in every servlet container on the market, including tomcat.

In short, I'd like to see a comparison of the features and availablity of what people actually use in their applications, rather than an entirely fudgable comparison of reported/unreported security flaws.

"None are more hopelessly enslaved than those who falsely believe they are free. -- Goethe"

iksrazal

Re:Just don't put .Net on a network

[dedazo]

The whole thing used DCOM

That's unfortunate, because .NET does not require DCOM at all.

DCOM uses RPC which means that firewalls have to allow the entire high port range

Yes, well, you can always open DCOMCNFG, switch to the protocols tab, select the TCP/IP entry and set the port range that suits you. Wow.

MS consultant all insisted this was standard and typical

An "MS consultant" told you you needed DCOM to jump over tiers with .NET and failed to tell you that you can select a port range to play nice with your firewall over the DMZ? Crap, I would have called his boss or the TAM at the regional office and have his ass fired.

consultant strongly urged not doing multi-tiered

You know what, while I don't doubt that there's someone dumb enough to recommend something like that out there, I really doubt it was an "MS consultant". Microsoft is moving away from heavy physical tier designs to avoid the wire overhead (which admittedly makes them look slightly stupid after years of telling everyone to use as many boxes as possible), but to recommend running the application and the database server on the same box is just plain retarded. MSCS (or whomever you were supposedly talking to) has some dumb people in the file and rank, but not *that* dumb.

I'm gonna have to call bullshit on your apocryphal story here, unless by "MS consultant" you mean some random dude that has an MCSD and has read "Software Fortresses" five times while moving his lips.

Re:Yeay! Security plus portability minus cost...

[Richard_at_work]

Java: price: free, well it is free Sure, but not as in beer. Can I independently create my own JVM and distribute it?

Well, actually, yes you can. Theres nothing stopping you reimplimenting a JVM to the released specifications, infact Kaffe is one such reimplementation. Go get a book detailing the VM specifications and how to implement a good VM from Sun!

Re:They looked at Java and improved it!

[zootm]

Net can have lots of security features as long as you can pump a string directly into win32 in half of the classes, which triggers a buffer overflow everything is null and void in this article.

You can't do that unless you're P/Invoking worse code, or running in the unsafe mode, both of which are similar to running a JNI interface with which you could do the same thing

The CLI system is sandboxed, the underlying API is hidden and — in general, unless there's a problem with the implementation of the system — its shortcomings are essentially hidden.

Re:.NET? Is this thing still around?

[rjshields]

If Sun adds real OOP features like multiple inheritance, operator overloading, traits, mixins, and introduces optional strong or weak dynamical typing

Multiple inheritance is best avoided for clarity (multiple interface inheritance is OK). Operator overloading is rarely useful and often abused. Java is a strongly typed language and this is not going to change ("dynamical typing" doesn't mean anything by the way).

Some of these points are misinformed and you missed out the things that bug people most about Java, the lack of deterministic finalisation and direct memory control, so it looks like your intellect is not superior after all. People who really do have superior intellect do not need to boast about it, it shows through in the things they do and say.

And that is the biggest problem.

[khasim]

It isn't which is really more "vulnerable".

It is how you define your criteria as to what is "vulnerable" and what is "safe".

They would have done a LOT better in just sticking to the design of each instead of counting admitted vulnerabilities and patches.

Microsoft has been known to sit on vulnerabilities for a LONG time (http://www.eeye.com/html/research/upcoming/index. html

Security starts with the security model. Here is where you'll see patches to disable stuff in a flawed model. You cannot just count the patches here, but they are useful for evaluating the model itself.

Then that model has to be implemented in code. This is where you'll see bug fixes for code errors.

The last thing to look at is any application built by someone else on that platform.

And one last item to consider. Any platform is only as "secure" as the level beneath it. If .Net can be exploited by a vulnerability in Windows, then it can be exploited. This is particularly important because Microsoft builds both platforms.

Here is where they get it wrong on Java:

Both platforms need some way of bootstrapping to install the initial classes and loading mechanisms. Java 1.0 used a trusted file path that gave full trust to any class stored on the path. Code on the system CLASSPATH was fully trusted, so problems occurred when untrusted code could be installed on the CLASSPATH [15]. Java 2 treats code found on the CLASSPATH as any other code, but maintains backwards compatibility by using the bootclasspath to identify completely trusted code necessary to bootstrap the class loader.

So, if Windows is compromised and code inserted to Java to run, then Java is at fault ... but if Windows is compromised and code is inserted for .Net to run, then that shouldn't count because the compromise happened before .Net was running.

Either you count it as a flaw in both, or you don't count it for either.