Gosling Claims Huge Security Hole in .NET 687
renai42 writes "Java creator James Gosling this week called Microsoft's decision to support C and C++ in the common language runtime in .NET one of the 'biggest and most offensive mistakes that they could have made.' Gosling further commented that by including the two languages into Microsoft's software development platform, the company 'has left open a security hole large enough to drive many, many large trucks through.'" Note that this isn't a particular vulnerability, just a system of typing that makes it easy to introduce vulnerabilities, which last time I checked, all C programmers deal with.
JNI (Score:3, Informative)
It's called unsafe code for a reason (Score:5, Informative)
Applications that require safety (for example running plugins downloaded from the net) simply don't allow those assemblies to be loaded.
Where is the problem again?
Re:Java is a type-safe language at the VM level... (Score:5, Informative)
Garbage collection in Java has been faster than free/malloc in C for years. This is in large part due to the fact that the runtime can recognize very short lived objects and put them on a special part of the heap.
It's not necessary to use unsafe languages to get performance any more.
Pat Niemeyer
Re:Java is a type-safe language at the VM level... (Score:1, Informative)
Re:Why oh why (Score:3, Informative)
So any decision to extend the use of C is just foolish. What is the purpose of doing this? If people must use horrible legacy code then just use it, but why drag that into new frameworks like .NET?
Managed C++ is basically a compatibility language. It exists to provide developers an easy way to interface legacy C/C++ code with .NET code. By providing MC++ Microsoft is actually providing a way for developers to slowly migrate to more modern languages (sorta like JNI with Java; imagine if you couldn't make system calls at all). Without it considerably more effort would be needed to port and allow existing code to interface with new systems.
Re:JNI (Score:5, Informative)
It is completely fair to point out that
Pat Niemeyer
Author of Learning Java, O'Reilly & Associates
Re:What's the flaw again? (Score:3, Informative)
It speaks to the purity of the language. Being able to deal with *everything* as an object is a distinct advantage since it allows you to, potentially, extend basic types into more complex ones and it also prevents you from having to "box" primitives in objects and "unbox" them on the way out.
BTW, JDK1.5 (aka Java 5) has a new feature called "autoboxing" which does the above boxing for you. This doesn't really count as those types being objects, it's more of a kludge than anything else.
This difference means that C#, from an OO standpoint, is a more pure language as opposed to Java which is a "hybrid" OO language.
GJC
Re:What's the flaw again? (Score:3, Informative)
It's ugly and non-orthoganal. Look at the Arrays [sun.com] class for example; there are dozens of duplicated methods that are identical except that they take bytes, chars, shorts, ints, etc. as arguments. I'd much rather have everything be a true object; any performance issues can be handled by the compiler, runtime, or Moore's law. Autoboxing helps, but better to fix it for real than with syntactic sugar.
Re:Phew! (Score:4, Informative)
Re:Phew! (Score:1, Informative)
Re:Advertisement? - You don't understand C (Score:2, Informative)
C is not for everyone.
For starters, it's a small language by design.
It was used to write OS code from the beginning.
It assumes you know what you are doing and allows you to break the rules to get it done.
If you want safety go back to Pascal...
Re:Java is a type-safe language at the VM level... (Score:5, Informative)
You're quite right that Java's speed is excellent these days (for non-GUI code, at least). I've spent a lot of time recently working with a large system that was first implemented in Java (by highly skilled developers) and then ported to C++ (by greenhorns). The C++ port is only 50-100% faster, which isn't worth the price in developer time that's been wasted on memory leaks and other forms of memory corruption that were never a factor in Java. Besides that, supporting multiple platforms with the C++ version is the #definition of pain.
However, the C++ version uses only about 1/4 or 1/5 as much memory as the Java version, and starts up far more quickly. If a *desktop* application needs to be deployed on older machines, or if the application is so memory-intensive it taxes the limits of today's server hardware, Java still falls flat.
Re:Advertisement? (Score:3, Informative)
The developer can choose to do whatever he/she wants. The nice thing about
The
C++ isn't so unsafe (Score:1, Informative)
Why is it that open source type people stay away from C++? The few open source C++ projects I have looked at look like they were written about 10 years ago.
If you're one of those who think C++ is just a big complicated mess, do yourself a favor and take a look at it now. I thought that not too long ago too but then I actually took the time to learn it well and it has completely changed the way I code (even in other languages!). Yes, it is big, and it is complicated, and it is most DEFINITELY not perfect. But it directly has facilities to support some very modern and powerful programming paradigms.
Re:Advertisement? (Score:3, Informative)
If that is the point, he's dead wrong.
Just like you can run Java code in or out of the sandbox, you can run
Re:Phew! (Score:3, Informative)
I'd like to point out that in this day and age most C programmers have heard about the problems and make some effort to prevent them. While programmers in "safe" languages (VB) generally have not heard of these problems, so while they are harder to create, those programmers are also less likely to recognize them. In fact problems in C are generally minor mistakes that are easy (though tedious) to fix, while in the other languages the same problem tends to be major design level issues that are hard to correct.
Re:Advertisement? (Score:3, Informative)
Yay, more rhetoric from Sun (Score:4, Informative)
In order to use "unsafe" code from managed C++ (or unsafe blocks in C#) you must have "FullTrust" security rights, otherwise the code fails to run.
You could shoot yourself in the foot but the runtime is perfectly capable of detecting and coping with corruption of the managed heap (generally by closing down the offending AppDomain.) Of course you can write a COM component in C++ and call it from dotnet, which is (in effect) the same exact thing! (I dare you to try and stop me from trashing Java or dotnet once I'm loaded in process via JNI or COM...)
CAS (Code Access Security) means that no other code can call your "unsafe" methods without FullTrust either, so there is no danger from code running off the web of doing this.
JNI is the same thing, Sun just gets to hide behind the lie since the risks aren't known by or integrated with the platform. At least with unsafe code the runtime is fully aware of that pointer voodoo magic you are trying to pull and can deal with it appropriately.
In other words Game Developer X can hand-tune the rendering algorithm inside the "unsafe" code areas, but develop the rest of the platform in fully managed code, making the development process much easier to write, test, and debug.
(As an aside, thanks to the antitrust ruling Microsoft is not allowed to comment on a great many things, including competitors. I don't know if this falls under that heading, but in many cases Microsoft's employees can't just come out and call bullshit when they see it for legal reasons.)
In conclusion: Sun should shut the hell up.
Re:Advertisement? (Score:4, Informative)
Unless you're talking about anonymous inner classes (a different animal, typically with a different purpose altogether when it comes to design motivation).
This seems to have been a matter of designer taste on the part of Hejlsberg. 2.0 should bring anonymous methods, which aims to solve the same type of problems anonymous classes did, in a neater way.
Re:Advertisement? (Score:3, Informative)
Not saying this can't be defeated but there are tools in the languages to protect yourself.
Re:Advertisement? (Score:1, Informative)
Just talking about V1.0 of C# here - I'm aware that Sun has copied many of those features in Java 1.5. For V2.0 there's a real implementation of generics rather than a kludge on type of the JVM... blah blah blah...
Gosling is actually wrong... (Score:1, Informative)
On top of this, allowing unsafe blocks of C/C++ is a good thing when people are porting to a managed language and need integration. It's pretty amazing that you can set a flag and run your old code in the new environment and call it from C#!
My impression of him has dropped significantly. Apparently experienced
Re:Advertisement? (Score:3, Informative)
It would pay for you to read:
http://msdn.microsoft.com/library/default.asp?url
malloc+free: fast, simple, and can be even faster (Score:5, Informative)
I don't know where you got your understanding of malloc, and especially free, but it's severely out of date. Knuth published about "Boundary Tags" no later than 1973 (citeseer is down, so no link). Saying that a coalesce operation "can be arbirarily slow" is just FUD. A boundary tag makes free() a fast O(1) operation: check the previous block in memory to see if it's free and if so join, a fast O(1) operation; check the next block in memory to see if it's free and if so coalesce; add free block to free-list, done. Yes, it's not zero work like a GC implementation sort-of is, but "arbitrarily slow"? It's basically at least as fast as malloc().
Allocation requests can hit disk, sure, but so can GC allocations even if they're just bumping a pointer: it all depends on the working set size. GC compaction can reduce fragmentation to reduce working set size, but that is only a big win if there's a lot of fragmentation, and most apps using a good malloc() don't exhibit that much. (It is also possible for a GC to rearrange memory so more in-working-set data is on pages together, reducing the working set page count without changing the total memory used. I don't know of any in-use implementations of this, since you need hardware support to know what objects are more-in-use; generally this is only available at the page level, where it's no help. I think maybe an early microde-based Smalltalk implementation might have done this.)
If your malloc has to walk giant free lists to find an open block, then sure, that can be slow. That's why people use trees of free lists based on size and such to make it more O(log N), and O(1) for small allocations. (On large allocations, actually using the memory amortizes the cost.) Read about dlmalloc [oswego.edu], for example.
Furthermore, let's not misrepresent GC. Stop-and-collect GCs have obvious extra costs beyond the free-of-charge free (or lack of need for one). Incremental GCs that don't pause are usually slower overall and only preferred for interactive programs. For example, incremental GCs usually require "write barriers" or "read barriers" which require several extra instruction on every fetch from memory or every write of a pointer variable in memory. This can add up across the entire program. Incremental GCs also tend to be conservative, and only end up collecting things that, say, were garbage at the start of the most recent collection round, and generational collectors allow garbage to collect in later generations for some time, so they don't actually necessarily have a smaller working set than a non-leaky malloc()/free() program.
Another big win in non-GC systems is that you can use pointers that don't come off the heap. That way you can avoid allocation and deallocation and GC entirely. (You can actually do some of this in a GC system too if it's a 'conservative' GC that copes with pointers into the middle of blocks. Those pretty much only get used for adding GC to C and C++, though.) Here are some common ways this happens:
Of course, doing all these things requires that you balance your different types of malloc()s with the correct, matching type of free(). In practice, GC proponents overestimate the diffi
Re:Advertisement? (Score:3, Informative)
Sigh. There are plenty of garbage collectors and boundscheckers for C/C++. Heck, there are several bounds checker extensions/patches for GCC that introduce bounds checking to both stack and heap. Boehm is a fine garbage collector if you like that sort of thing. They go back at least 10 years.
Combined with a non-executable stack and heap, randomized address space layout and signed return addresses (StackGuard XORs with a random value and verifies before returning), it becomes extremely difficult to exploit.
And of course with C++, you don't actually have to use pointers or arrays. There are enough nice safe standard containers.. well I won't go into that.
That said, not all security exploits are buffer overflow related. There were plenty of security exploits before buffer overflows became popular and there are still plenty today. They can exist in Java just as easily as anywhere else. You pass an unescaped buffer from a user to a db call, no amount of VM is going to help you avoid someone taking advantage of it.
Re:Advertisement? (Score:3, Informative)
Now onto .NET. C++ is fairly easy to pull into a project - write some garbage collection safe wrappers around your "legacy" code and now it runs in .NET. And via PInvoke you can call native methods easily too. And then there's COM interop which pulls in ActiveX controls. That's all good and well, but it also means that lots of projects are not "pure" - they're polluted with Win32 crap and generally not portable.
That's probably what gets to Gosling - that .NET is touted as a portable development platform but it isn't. Projects are infested with unpure, unsafe and platform-specific code. Microsoft can preach portability but they know that very few people will be disciplined enough to bother with it. Thus people are tied to Win32 even when they're using a allegedly portable runtime. Even the likes of Mono only gets around this by pulling in winelib.