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.
C++ allowed you to do arbitrary casting, arbitrary adding of images and pointers, and converting them back and forth between pointers in a very, very unstructured way.
.NET and the unsafe keyword for managed code are there to restrict how you use native objects.
.NET handles managed code, which java can't do so easily (remember jini? Me neither) - so what .NET should really do according to Gosling is have a sandbox runtime with no severely restricted access to the native interfaces - to hell with performance compared no native methods? Oh, that'll be just like ummm .. java then.
Unstructured? Yes. A huge security hole? No more than any other language using COM objects. You can write crappy spaghetti code in any language. The type interface for
What Gosling is really criticising is the way
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
Actually, this is the kind of thing I like to see. It is definitely technology related; it's omission would be an error, IMO. If I'd seen this someplace else, and didn't see a discussion of it on /., I'd be concerned.
The fact that the editors actually chose to point out the flaw in the argument (in MS' favor!!!), rather than adding to the sensationalism is a welcome and refreshing change.
You imply that compiled C code is faster than compiled C++ code, which IME is rarely the case these days. In particular, optimisations performed by C++ compilers have almost caught up with their C brethren. With almost perfect zero-overhead implementations of all the major C++-only language features now in common use and the added performance boost from things like inlined code in templates, the balance often tips significantly in C++'s favour now.
Can you give some examples of high quality numerical libraries written in pure Java (i.e., without JNI)?
Disclaimer: I'm a professional C++ developer, and I write high performance maths libraries for a living.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
It's irrelevant, actually. A bug is a bug. You can make them in any language. The consequences of the potential bugs are what matters. But only the implementation defines what a "buffer overflow" will actually do. Granted you can try and write past some allocated buffer in C (and C++). That doesn't mean the write should actually occur. That's the responsibility of the implementation, and mostly of the underlying operating system. I already said that earlier: the major problem we have been facing for decades on mainstream systems (and even some critical servers) is, in my opinion:
Allowing executing code from a purely 'data memory' space. That should never, ever be possible under any circumstances. I'll fight for that cause if I have to.
Poor 'data memory' protection. Ideally, the OS should be able to protect individual data areas, down to application buffers and variables. There is nothing that would prevent from writing a C or C++ compiler for such an environment. Absolutely nothing.
You may not be able to "overflow" some data buffer in Java, but you can always write garbage to it. That's the same. As I said, the languages need not be fixed. The systems and the memory models do.
Free and malloc are NOT very simple algorithms. They have arbitrary complexity. malloc ranges from the normal case of about 100 instructions (when a block of memory of the correct size is available) to unbounded (when data must be paged out to make enough room for the new allocation and the data for tracking it). Free can also be arbitrarily slow, as releasing one block may trigger a coalesce operation.
So you have to measure time per malloc and time per free, then total them up and compare it to GC's time per allocation and time spent in GC. In some cases, one will be significantly larger than the other, but in most nontrivial programs, using modern malloc/free and modern GC, it comes out pretty close to even.
Some argue that the "pause" from GC is a problem. Maybe. Except that as mentioned before, malloc can also "pause" for arbitrarily long times. And a lot of work has been done on "concurrent" GC that doesn't pause. If you can afford paging in from disk (swap file), you can also afford GC's "pause".
Finally, when you write a big program, you spend incredible effort in your program tracking memory. That takes cycles. "If x then save a copy cause we'll have to free it later, etc."
The bottom line is that there are some cases where GC still won't work, but those cases are getting smaller and smaller. For most cases, the argument that GC is slow or inefficient just isn't true. Go do some real benchmarks, or go study up on the already published benchmarks. GC is pretty efficient, and malloc/free has no significant speed advantage anymore.
Time flies like an arrow. Fruit flies like a banana.
I think the point is that it's much easier to inadvertently create security holes when you write code in lower level languages like C. Lots of excellent programmers have written code with security problems, simply because they're focusing on making their code work and not thinking about security. It's an extremely common problem, and while it may be a problem with the developer's focus, it's not generally a problem of low skill levels.
Sorry. This doesn't really cut it. Note the dates on the website. Its been moribund for about 2-3 years (the unfortunate side effects of downsizing useful government initiatives to fund the military/security complex and tax cuts, but that is another sad story).
Of the two "numeric" libraries mentioned on the website only one handles complex numbers and the implementation in java leaves much to be desired (relative to assembly or C). To my knowledge, the Lau Numerical libraries based on algol routines are good and probably the most extensive available in java, but there are numerous performance issues relative to FORTRAN and only some are even marginally optimized to run in parallel.
With the advent of dual core opterons in the near future and the commercialization of grid computing, as a SUNW investor, I'm still hopeful that James Gosling and Sun will step up to the plate here. So far, I haven't seen my fervent hopes come true, but perhaps you know something I don't. If so, I'd love to hear about it.
Investing aside, this is really unfortunate as 1) I love to program in java, 2) my area of interest is in the application of numeric algorithms for bioimaging and 3) I would like to make better use of such in threaded, object oriented/actionlistener/GUI contexts for which java excels. When one attempts to call numeric libraries to produce actionlisteners attached to dynamic graphics calls, even minor performance penalties can notably degrade graphics performance particularly when matrix sizes that result from even NTSC video resolutions.
I'm not too thrilled about invoking JNI as there can be a substantial overhead on calling native code such as BLAS from within java (not to mention that it is complicated, even for relatively simple function calls and of course non portable). This also ignores the problems raised about java's floating point representation and its inability to code for addition and multiplication within a single clock cycle as can be done in FORTRAN. Such problems are especially acute when dealing with eigenvalue problems in which the results contain roots with multiplicity and where ill-conditioning can be an issue for iterative solutions. Obviously, 64 bits will help in such circumstances, but its not really a general panacea.
This is all somewhat off topic, but I am always on the lookout for someone who knows better than I, as I am keen to prove myself wrong (and hence be in the position to write more effective java code).
It is ironic that Sun has move aggressively to grid computing, but has still not fully address limitations within java's numeric routines. James Gosling made some noises about attending to these defects on the forum you mentioned quite a few years ago, but to my knowledge no real response to the criticisms raised in references to be found via the website you cite. At least none that I am aware of.
Man, why don't you tell us why you really hate Java.
No, Java is not suitable (or useful) for what an engineer would call a "critical" application. Those applications are coded in C or C++ (or Assembler).
I'm using java because that was the business decision made by my boss (or my boss' boss). So I'm just told what I have to do (what interface the user expects, what system I have to connect to, etc.) But for the company I work for, Java might be a critical part of their business plan.
For example, you won't find java in a heart monitor in the hospital but probably find the server that keeps your health records is done in Java. Whoever is developing the Health record system can (more or less) pass the code to a new developer to continue working on it without expecting the new guy to be an expert on that particular system.
Anyway, this could all be bullshit if sound coding practices are not follow on ANY language.
In my current job, which involves quite a bit of C#, I had the opportunity to port large chunks of our legacy application from C++ to Managed C++. We didn't gain security benefits, nor did we gain speed; we didn't loose any either. However we gained a lot of maintainability since we now have a single stack-trace to deal with that bridges all of the languages that we have (now reduced to C# and C++ -- down significantly from when we relied heavily on COM)
The fact that MS gave us that choice is wonderful. If we wanted to be using JNI (which I had the unlucky opportunity to use), we'd not have made much progress at all.
Why do people think of Pascal as inherently safe? If you want to mess with pointers, it's really rather easy. Stick 'em in a variant (union) record, do your arithmetic against another named integer, and there you go. I mean really ...
"Object-oriented programming" is ill-defined. It encompasses a lot of languages that go about it in entirely different ways. To me, the most it can mean is "calling functions with an assumed this pointer." What does OO mean to you? Virtuals? What makes it "real"?
There are benefits to C beyond speed and direct access to memory, hardware, etc. People seem to forget that for us to make software "work together", calling conventions across libraries need to be compatible. Which is why we picked C calling conventions. It's not necessarily the most expressive if you're into fancy things, but it is flexible enough for most everything. My main problem with Java isn't the language -- it's the libraries. Lots of them, packaged in their own special way, not really designed for use by any language.
Languages, most of the time, aren't the issue. We haven't gained all that many 'new' features with new languages, at least not anything we can't easily live without. Access to symbols is an issue, however, and a really important one from the point of view of integration, code re-use, and even making sure you're using trusted/proven code.
Regardless of buffer overflows, you can still write infinite loops, incorrect logic, etc. in just about any language. These language wars are about markets -- they're about money.
.NET and Java are both insecure, because they both rely on too much code written in unsafe languages.
.NET and Java allow any arbitrary application to load unsafe code.
.NET will never be secure with its current architecture. Neither will Java. I am personally convinced that language-based security can be made to work (using a capability security model), but not the way Microsoft or Sun are doing it.
If you want to implement a system based on language-level security using a mixture of code in safe and unsafe languages, as little as possible of the system must be written in the unsafe language(s), and that part must be treated as being in the system TCB.
Some unsafe code is unavoidable if you want the system to be able to use OS facilities on Windows and Unix. However, it must be written by people who know how to write secure code, and gone over with a fine-tooth comb for possible weaknesses.
It is completely disingenuous for either Microsoft or Sun to claim that these platforms are secure, given that their implementations depend on millions of lines of unsafe-language code that no-one is ever going to review properly. Even more so since both
So basically, Gosling's argument is correct: