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.
Good thing Linux isn't written in...
Oh. Never mind!
I actually RTFA since it included a sensationalistic phrase like "biggest and most offensive mistakes that they could have made."
.NET platform. I certainly wouldn't call this a huge mistake made by MS.
To me, it sounded like a big advertisement for Java.
It's the developers decision to use unsafe code in the
A hunting rifle can be used to kill people. Does that mean the trigger should only work after inserting a valid and current hunting license?
CowboyNeal is defending Microsoft. Someone take a screengrab, Slashdot's been hacked!
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.
I don't disagree with Microsofts position. Yes errors are possible, but it's a programming language, and not Microsofts responsibility. With a case like programming it is the programmers responsibility to release code without exploits... c and c++ are fast, they have many advantages other languages don't have (such as Java) if a programmer decides to take advantage of that, with a slight bump in risk, then I say more power to them.
WANNAWIKI Wannawiki WannaWiki WANNAWIKI!
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.
I guess he forgot all about JNI. Now don't get me wrong I like java and would not even think about messing with .NOT but quit telling lies, java has the same exact hole.
Got Code?
the company 'has left open a security hole large enough to drive many, many large trucks through.'"
Like, say, a truck about the size of Sun's Java runtime environment.
The coolest voice ever.
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.
I hate to defend MS on this, but you have to have a certain type of permission to call unsafe code. As soon as you call anything such as that, the whole program becomes immediately unverifiable.
New languages such as C# and Visual Basic.NET only produce managed code.
Hey, what about the keyword unsafe in C#? Sheesh.
Unsafe code is not subject to security checks of the .NET virtual machine. To execute unsafe code, you have to specifically grant those rights to the executing program. It is not something automatic.
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?
Gosling that Java is inherently insecure, as it is written in C.
Assemblies (.NET DLLs and EXEs) require special permission to run unsafe code. In the eyes of .NET, all unmanaged code or any use of pointers is considered unsafe. This includes every C/C++ application ever. .NET's philosophy on security is clear: .NET assembly is secure except by special request to use unsafe code. Over time, all assemblies should be completely void of unsafe code except for assemblies from trusted sources.
A
For example: The end user can grant unsafe permissions to the Microsoft Managed DirectX assemblies. Anyone could then use these assemblies without needing unsafe permissions. If you trust MS MDX to use unsafe code, and you trust the app you downloaded to use MS MDX, you don't need to give the app permission to use unsafe code.
http://brandonbloom.name
It's the same with C. We should know by now "you cannot use C to handle untrusted data (ie, data from untrusted machines on the net)". All such data need to be handled in a sandboxed system, a system with safe memory access. This means something like Java or similar things.
A lot of people will make posts that say things like "C doesn't cause the problems, it's incompetent or lazy programmers who cause the problems." Whatever. No excuse. That's like saying "we shouldn't need seat belts or airbags; all we need is to make sure that drivers don't make mistakes." Drivers and programmers do make mistakes and that's why we need safety mechanisms in both cases. C provides none. Programming in C is like driving around in a car from the fifties, with no seat belts, no airbags, no head rests, no ABS.
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?
It does not compute, for me at least.
No longer should homes be built using nails. All new homes should be built with really strong glue. Even though nails are faster and easier to work with, a carpenter might accidentally smash his thumb with a hammer. Plus, nails contain metal which may warp your home in the event a huge magnet is placed near the house.
--The Elmer's Glue Foundation for Strength and Security
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
Just curious... What's wrong with that?
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
Gregory Casamento
## Chief Maintainer for GNUstep
Just curious... What's wrong with that?
It's ugly and non-orthoganal. Look at the Arrays 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.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
Gosling is dead wrong. I believe that Microsoft will soon prove they are capable of even bigger and more offensive security mistakes.
Also, the choice to actually use .NET is at least as big of a security error.
I'm an American. I love this country and the freedoms that we used to have.
"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."
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...
After reading the comments to this post, I have finally lost my faith in the industry... C was around before your 'secure' languages, and C will be around long after your 'secure' languages become outdated/obsolete.
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
You arae kidding, right? Do you seriously believe Java is the first or only language to guarantee runtime safety? Safe languages are the rule, not the exception.
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.
C# distinguishes safe and unsafe code. C#'s safe code is as safe as "pure" Java code. You can think of C#'s unsafe code (or its equivalent in C/C++) as code linked in through the JNI interface, except that C#'s unsafe code has far better error checking and integration with the C# language than anything invoked through JNI.
Altogether, C#'s "unsafe" construct results in safer and more portable code than the Java equivalent, native code linked in through JNI.
Pat Niemeyer, Author of Learning Java, O'Reilly & Associates and the BeanShell Java Scripting language.
Well, then I suggest you learn some languages other than Java before making such ridiculous statements.
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.
Java is way way over hyped, not to mention proprietary.
You can program C++ using classes such as std::string in a manner similar to the java string class. This eliminates most of the buffer overrun issues that plague many C programs. But unlike java you can bit twiddle when you need to, ideally encapsulating your twiddling in a class.
Java is simply a straight jacket for programmers, but straight jackets can't prevent logic errors. Your data is still at risk through stupid programming mistakes.
I don't like Microsoft just as much as the next Linux user, but come on... Good programmers know how to deal with the problems inherent in C/C++. Not to mention that those problems extending beyond .NET to all C/C++ environments.
Besides, why should anyone listen to the anti-C++ rantings of one of the top dogs in Java world. Just remember that today's security is tomorrow vulnerability.
I guess that's why there's no java native interf...
oh. nevermind.
Like we really need more Rhetoric from Sun... but I'll deal with his concerns anyway.
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.
Natural != (nontoxic || beneficial)
The reason you've probably never seen it, and the reason your code snippet works, is because C# is smart enough to automatically insert box and unbox instructions where appropriate.
If you want to prove this to yourself, try reading the ECMA Standard 335, which covers the topic.
Karma: -2147483648 (Mostly affected by integer overflow)
Yes, CowboyNeal, but do they want to deal with it, and should they deal with it?
For every programmer who reads security bulletins and keeps tabs on the latest string-copying buffer overflow issues and fundamental security principles, there are a hundred who don't know or care.
C is a high-level language that:
Programmers want to be productive -- most want to make things make colourful stuff happen on the screen, not fiddle around with buffer guard code. So the more security can be built into the language and its running environment, the better.
Many languages, such as Python or Ruby, provide security against what I mention in my first bullet, through a virtual machine. They're not impenetrable, and are of course, as dynamic languages, subject to a different class of security holes (eg., string evaluation of code), but they're a step up from the C level.
Other languages, like Java, provide capability-based security models, allowing for sandbox environments with fine-grained control over what a program may or may not do. Java's security system is ambitious, but since most Java apps run on the server these days, it's not frequently used, and except for browser applets, Java code tend to run unchecked.
In a way, Java tries to do what the OS should be doing. Programs run on behalf of its human user, and their destructive power is scary. Why should any given program running on my PC have full access to my documents or personal data? As we're entering an age where we have more and smaller programs, and the difference between "my PC" and "the net" is increasingly blurred. Operating systems need to evolve into being able to distinguish between different capabilities it can grant to programs, or processes -- we need to think about our programs as servants that are doing work for us by proxy.
The same way you wouldn't let a personal servant manage your credit cards, you don't want to let your program do it -- unless, of course, it was a servant (or, following this metaphor, program) hired to deal with credit cards, which introduces the idea of trust. The personal accountant trusts the bank clerk, who trusts the people handling the vault, who trust the people who built the vault, and so on.
In short, any modern computer system needs to support the notions of delegated powers, and trust.
Programmers will certainly never stop having to consider vulnerabilities in code. But painstakingly working around pitfalls inherent in one's language, be it C or indeed .NET -- we need to evolve past that. The users, upon whom we exert so much power, certainly deserve it.
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.
Gosling Emacs (written by none other than James Gosling) has many HUGE security holes that you can pilot an aircraft carrier through.
Emacs has a notorious "shell" facility that can actually run a shell and send it arbitrary commands!!!
In fact, there's even a built-in scripting langauge called "Mocklisp" that enables hackers and viruses to totally reprogram the behavior of the editor (and it looks like Lisp, but without any of those confusing lexical closures and list processing functions).
Gosling Emacs is actually spyware, because it has a hidden "keyboard macro" facility that can spy on every character you type! Emacs is also malware, because at any point it can instantly undo any editing changes you've made!
One of the biggest most offensive mistakes is that James Gosling has not fixed these huge security holes in Emacs, after all these years. In fact, many of the security holes have been reimplemented in another notorious piece of communist spyware called Gnu Emacs!
All Emacs should be banned!!!
-Don
Take a look and feel free: http://www.PieMenu.com
Incompetence leads to trouble in any language. For instance, a recursive function which does not enforce a recursion limit may:
- segfault in C
- throw an unhandled exception in python
- churn up 2GB swap in java (or something similar)
In any case, think DoS. The solution is to program competently, regardless of language.
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, 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
i was thinking more along the lines of Lisp or Scheme. please do your own research, I really don't have time to school a newbie. Java is nothing new. Hell, even pascal had P-code. Welcome to the 1980s and prior. GC is some new technology according to Java people.. what a fucking joke.
Dijkstra Considered Dead
Rule:
If you don't need to spend 5-10% of your development time to speed/size optimizing your program to make it useable, you are not using language/abstractions that is high level enough to your task.
Explanation:
If I use high level languge (say Haskell/OCaml/Clean/Common Lisp) and use all it's abstarction powers, program code will usually be 10-50% of the size compared to same program written in C/C++ (and Even Java). Now that X% (50-90%) of slack will take X% of development time and contain X% of the bugs. It will make the program much harder to change too. You can see that the 5-10% spent into optimization (you can even write the fast parts in C if you like) will pay.
If you don't belive, compare code of gnu-arch arch to darcs. Both are similar version control systems.
Dyslexics have more fnu.
Java has several pretty fundamental disadvantages when it comes to serious numerical work, compared to a language like C or C++.
The most obvious is the "everything is an object" principle. If you can't create value types for things like vectors or complex numbers, you're imposing performance overheads for dereferencing before you even start doing any maths.
Moreover, serious maths work often involves large data sets. We work with graphs with many thousands of nodes pretty routinely, which can make fine control of how much memory each node occupies very important even on powerful workstations with lots of RAM. When you're constrained to do everything using indirection and using a limited set of primitive types, this is difficult to impossible.
Then of course there's Java's floating point requirements, which were technically impossible to meet for a long time IIRC. I'm not sure whether they've been fixed even today, but certainly if you require a VM to do a manual series expansion to calculate trigonometric functions according to your strict requirements, while everyone else is using a single FPU instruction and getting an answer that is either identical or off by one in the last binary place, you are not going to be winning in the performance stakes.
The bottom line is that the same things that are strengths for safety/security in general applications -- lack of low-level control and banning dangerous primitive constructs -- can be huge weaknesses when those are necessary to achieve an acceptable result in the real world.
Despite Sun's propaganda, I suspect C and C++ are still considerably more portable than Java. I don't know how you managed to get code only compiling on one machine on one platform. We routinely build our code on something like 15 different compiler/platform combinations, with many more having come and gone in the past, and anything not building on any platform is usually an old compiler failing to support a standard feature properly so we rewrite that code to work around the problem. Java's "perfectly portable" floating point requirements might be an advantage in this area -- we do occasionally see very minor discrepancies in the outputs on different platforms -- but I don't see Java as an advantage for actually compiling your code across different platforms.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Talk about not eating your own dogfood?
It's a very dark ride.
.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: