Comparison of Java and .NET security 461
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."
PDF text (Score:5, Informative)
Re:They looked at Java and improved it! (Score:2, Informative)
If it does, that's a good (although somewhat late) improvement (which should've been a free upgrade, since I consider the absence of that 'feature' a bug).
Just don't put .Net on a network (Score:1, Informative)
I notice the article did not talk much about the implications of having a .Net implementation on your network.
The one (and only) multi-tiered .Net implementation I have had to work with was a networking nightmare. The whole thing used DCOM which is a total pain in the ass. No NAT'ing (DCOM doesn't function across NAT) means that production DMZ's had to have routeable IP's. DCOM uses RPC which means that firewalls have to allow the entire high port range (>1024) between tiers. The transaction protocol in the framework likes to talk all the way from web layer to db layer so defense in depth is pretty much thrown out the window.
It may be that there is a way to use .Net without running into these issues, but the developers and the MS consultant all insisted this was standard and typical. Of course, they all also insisted that the environment would be better off flat and the MS consultant strongly urged not doing multi-tiered. So I suppose if you don't mind having your SQL server in the DMZ .Net is great.
Didn't like it. No sir. Not at all.
Re:Source code access (Score:5, Informative)
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"
Re:Source code access (Score:3, Informative)
Heh, that part is quite a troll.
I use Java apps daily (Eclipse, Moneydance, JAlbum), and now that you make me think of it, they might not be "lightning fast", but they're fast enough that I don't think about their speed. In my book, that's the definition of being "fast enough".
I don't have experience with
Anyway, Java is not "slow" anymore, it may be not as fast as others, but it's fast enough.
Re:They looked at Java and improved it! (Score:2, Informative)
Open source java security projects (Score:5, Informative)
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/ [sourceforge.net]
2) XML Encryption and XML Digital Signatures. Used in Web Service security or independently.
http://xml.apache.org/security/ [apache.org]
http://ws.apache.org/wss4j/ [apache.org]
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 (Score:5, Informative)
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... (Score:5, Informative)
Well, actually, yes you can. Theres nothing stopping you reimplimenting a JVM to the released specifications, infact Kaffe [kaffe.org] is one such reimplementation. Go get a book detailing the VM specifications and how to implement a good VM from Sun! [sun.com]
Re:They looked at Java and improved it! (Score:5, Informative)
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? (Score:5, Informative)
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.
It's been done (Score:3, Informative)
This is news? ONJava [onjava.com] did a detailed, four-part analysis of .Net and Java security a year or so ago:
What is with all this willful ignorance? (Score:3, Informative)
AND, Mono and
I have written GTK# apps in VS.NET and run it on my Windows and SuSE box with ZERO modifications.
If you want to bash something, you should probably learn a bit more about it. That's the reason I read the Bible multiple times: so I can refute Bible thumpers' arguments.
Re:Interoperability? (Score:3, Informative)
- Java interoperability is extremely important. It's not about running the same code on different platforms, though. It's more about being able to switch out the platform when we need to (e.g. going from Wintel servers, to Linux and z/OS)
- .NET is not knocking the socks off of Java. They are both shaping up to find their places. In our org, anything we write is Java (any tier, including clients where balls-to-the-wall performance is required). When we buy stuff, we look at Java (very few products) and
.NET (more products).
- Web Services are simply grand. But someone please wake me up when there's a full-featured implementation that's interoperable. Until then, Java has not lost any advatange here (if there ever was an advantage here).
- your comments about 'beloved Linux desktops' simply describes the power of a Web interface, which is not specific to ASP.NET. Incidently, a Web interface is not always the right solution, so how does the Linux front-end play with the Windows back-end there?
Not trying to diss you here. Just trying to give some perspective from this corner.Re:Nonsense, utter nonsense (Score:1, Informative)
But then you have to typecast, which spoils it all. Typecasting is a memory re-interpretation in C/C++. If it's not compatible in C, then you will start garbling memory in arbitrary ways.
In a secure language architecture, OTOH, it's an attempt to assign to a compatible type...and if that type is not compatible the VM will throw an exception. Furthermore, the stringent typesafety requirements make it absolutely necessary that garbage collection is used so that pointers to deallocated data, orphaned data, etc are disallowed.
Another important thing is no information hiding in C, So you won't get compiler errors when you try to go around the public interfaces (direct access, casting, etc). Even in C++, if you add a new private data member you have to re-compile the clients of the library...because everything in C/C++ is concerned with the actual byte layout of everything. this is a profoundly retarded way to make shrinkwrapped libraries.
Java/.NET by contrast don't really define byte layout. In fact, memory layout could be randomized for security purposes for all you know. Datastructures could be much smaller or larger than you imagine by just looking at its members. As an example, he String classes in Java/.NET are doing a lot of magical stuff to share memory.
And of course you missed the whole point of why you can't use any derivative of C for executing semi-trusted code. You can't allow type violations of any kind (buffer overflows, pointer arithmetic), Any security holes discovered in these VMs are business as usual in C (type violations, memory violations, flow violations) because everything in C is accomplished through some form of pointer arithmetic.
In any case, this is no attempt to bash C. I like C and C++ for what they were intended. It's just that C will never address the issue of protecting the user from his own processes, which is what VM security is all about. There are times when you need to protect yourself even from code that's been signed by an entity that you trust.
This is something that you can't address the same way that you protect the OS from its users (disallowing syscalls, using virtual memory pages). You need to be able to make calls out to dangerous functions, but be able to apply fine-grained policies to how this is allowed. And you can't enforce the policies if you can walk around them by violating the typesystem.
BTW, the whole CVE comparison thing from the article was a bit unfair because the CVEs from before
System.setSecurityManager() does this... (Score:1, Informative)
Writing a Security Manager [sun.com]
You can just do this at server startup and lock it down as much as you want.
-- ac at home
Re:Yeay! Security plus portability minus cost... (Score:3, Informative)
You can write in lots of nice languages for it, wheras Java afaik only has Java and Ruby.
No offense, but I guess you don't know much. Here are just a few of the available languages for the JVM:
Re:Professionals use C for everything (Score:3, Informative)
These languages are less error prone and easier to debug. Therefore, they are the tool of choice for someone to create a program within a certain timeframe, a program which sources that can be read and changed for years to come (if well documented).
And yes, they use OO. Things like streams and those nice GUI's wouldn't be possible without it. Maybe namespaces are even more important though.
Re:PFMUTA blocks (Score:1, Informative)
What about unsafe code (Score:3, Informative)
The study authors say "Since a security policy cannot be enforced on unmanaged code, we only consider managed code." Given that most C# applications use unmanaged code, they are potentially vulnerable to buffer overflow attacks and the like.
C# has been criticised repeatdely in the security community for this feature. Java always runs in safe or managed mode and is therefore more secure than C#.
For more on what unsafe code means see http://msdn.microsoft.com/library/default.asp?url= /library/en-us/dncscol/html/Csharp10182001.asp [microsoft.com]
That the authors of the paper make conclusions about C# security, while deliberatley excluding a gaping hole, and the papers appearance on an MS site leads me to the belief that the paper was probably sponsored by MS and they directed the study authors to exclude unmanaged code from the scope.
Bill Caelli, one of the world's leading security experts, humiliated a Microsoft representative over unsafe code and stated that "Microsoft had missed an historic opporunity to improve security in their products".
Re:Except... (Score:3, Informative)
Welcome to the world of hackers making life better
http://www.mono-project.com/Main_Page [mono-project.com]
There are at least 9 security flaws in .NET (Score:3, Informative)
Re:In addition (Score:2, Informative)
Java isn't
That's right, there's no open [gnu.org] source [gnu.org] Java [kaffe.org] solutions [nongnu.org]. You also can't download the source code [sun.com].
Oh wait...
Re:Had to switch from Java to .NET (Score:3, Informative)
Re:.NET? Is this thing still around? (Score:3, Informative)
I don't mean to insult you, but you have a misunderstanding. Java does not have destructors. Finalizers are not destructors. Once you accept that, you wont ask for certain behavior of destructors to be attributed to finalizers. finalizers are just there for testing and information. No production environment should use them. In fact, in production, they should disappear like asserts...
Why do you need a call to x.close in the finalizer? You opened it, you close it.
My solution has been to do a sort of c++ style thing. I have a reference counting system, and when they reach 0, I close the thing myself. Java does not use reference counting to know when to release an object, so perhaps thats why they dont have a destructor.
.NET vs Java security......??? (Score:2, Informative)
And that is the biggest problem. (Score:5, Informative)
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
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
Here is where they get it wrong on Java: So, if Windows is compromised and code inserted to Java to run, then Java is at fault
Either you count it as a flaw in both, or you don't count it for either.