Slashdot Mirror
Gosling Claims Huge Security Hole in .NET
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.
So you mean to tell me that the father of Java won't be slightly bias?
.NET is great (for its target area)
C'mon now. There is no vulnerability. Don't post this sort of crap. Its strictly knee-jerk material meant to bend a few people out of shape and start flames.
J2EE is great (for its target area)
Both are secure, stable and reasonably fast if you are a GOOD programmer. ANYONE who does ANY C or C++ code that will be used in industry needs to ENSURE that they just take a few extra precautions and are aware of secure coding techniques in both languages. Its rather quite simple.
To sum it up: nothing to see here folks.
This could have just as easily read "Java Creator Disses Rival Product, Ignores Flaws in His Own."
In Java, everything is an object! Oh...except for the basic types, you need to use object wrappers for those.
This is what really distinguishes Java from other languages. The Java verifier is a sort of theorum prover that examines the byte-code and can guarantee that it does not violate certain rules such as forging the type of a reference or under/over-flowing the stack. Because this is done at the verify stage it is still possible to compile the bytecode down to machine level instructions after that and run at full speed. This is why Java is both safe and fast.
To support C/C++ semantics (ad-hoc pointers) you'd have to throw all that out the window and I assume that's what he's talking about.
Pat Niemeyer,
Author of Learning Java, O'Reilly & Associates and the BeanShell Java Scripting language.
As much as I think his presentation method is tacky, I can agree with some of what he says.
C and C++ allow for buffer overflows. They allow for improper or intentional coding to cause software to try to violate memory space of other functions or programs. They allow for memory allocation without necessarily providing any cleanup later. In the hands of bad, sloppy, lazy, or malicious programmers these traits have always proven to be a problem time and again on many different platforms. This doesn't mean that these languages are the wrong tool; I'd argue that part of Linux's success is because the kernel and most of the GNU-implemented services are written in these languages, which are flexible. Too much flexibility for the wrong purpose leads to problems though, just as too much rigidity leads to problems when things need to be flexible.
Do not look into laser with remaining eye.
He's not wrong about the pitfalls of C/C++. It's just that his argument is downright silly when taken in the appropriate context. The .NET "unsafe" code segments are really no different than JNI, except that they integrate much more cleanly into the platform. As much as I dislike Microsoft in general, .NET is an extremely well designed and secure platform. I say this as someone who has spent almost a decade making a living performing software security assessments and developing secure architectures. If you take the time to research it you will find that .NET really feels like the next incremental step after Java, and it takes advantage of a decade's lessons learned in Java.
No offense, but give a fool a hammer and he'll crack his skull. C is not inherently insecure. C++ is not inherently insecure. If you don't know how to program, please step aside and let others through. I am not some sort of anti-managed-language zealot, I love Python, but to claim that C *as a language* has a terrible security track record is ridiculous. The applications, not the language, might have a terrible track record due to the ineptness of the programmer.
I mean seriously, this is like claiming ASSEMBLY is a worthless insecure language because you can hang the system while in supervisor mode, due to ineptness? Sheesh.
"No offense, but give a fool a hammer and he'll crack his skull. C is not inherently insecure. C++ is not inherently insecure. If you don't know how to program, please step aside and let others through. I am not some sort of anti-managed-language zealot, I love Python, but to claim that C *as a language* has a terrible security track record is ridiculous. The applications, not the language, might have a terrible track record due to the ineptness of the programmer."
That's just restating the question.
If managed languages make a certain class of exploits impossible or very unlikely while C doesn't, then C is insecure relative to those languages.
A good C programmer might be able to cut the exploit rate down to some very small value, but they're going to work pretty hard to get to that point while people in managed languages get it for free. And good C programmers still fuck up sometimes.
Of course, there's other ways to screw up. No language is immune from security problems. Using a "managed" language is nothing more than risk management, but it's pretty effective.
I rarely criticize things I don't care about.