Forgot your password?
typodupeerror
Security Microsoft Java Programming Sun Microsystems

Gosling Claims Huge Security Hole in .NET 687

Posted by CowboyNeal
from the throwing-stones dept.
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.
This discussion has been archived. No new comments can be posted.

Gosling Claims Huge Security Hole in .NET

Comments Filter:
  • Phew! (Score:5, Funny)

    by rackhamh (217889) on Friday February 04, 2005 @08:50PM (#11578838)
    Good thing Linux isn't written in...

    Oh. Never mind!
    • Its good to run c code on your machine. You don't want applets running it.
      • Re:Phew! (Score:3, Insightful)

        C/C++ programs have terrible security track records. They're behind basically every arbitrary code exploit out there. That class of bug just doesn't happen in managed languages. And I don't mean just Java and .NET. An open source example is Python.
        • Re:Phew! (Score:4, Informative)

          by DrLZRDMN (728996) on Friday February 04, 2005 @09:32PM (#11579198)
          Id like to see a kernel written in either language.
          • Re:Phew! (Score:3, Insightful)

            by bnenning (58349)
            Id like to see a kernel written in either language.

            Fair enough, but at least 90% of the stuff written in C and C++ doesn't need to be.
            • Re:Phew! (Score:5, Insightful)

              by andreyw (798182) on Friday February 04, 2005 @09:59PM (#11579378) Homepage
              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.
              • Re:Phew! (Score:5, Interesting)

                by pivo (11957) on Friday February 04, 2005 @10:26PM (#11579559)
                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.

                • Re:Phew! (Score:3, Informative)

                  by bluGill (862)

                  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 co

                • Re:Phew! (Score:3, Funny)

                  by dasunt (249686)

                  Just imagine how secure the world would be if we wrote everything in PHP! :)

              • Re:Phew! (Score:5, Insightful)

                by owlstead (636356) on Friday February 04, 2005 @11:02PM (#11579759)
                Pffft, I am working with a couple of high grade C++ programmers. When they go down using pointers etc. you can be sure they introduce some overflow errors. You need at least a code checker to make sure that the most common mistakes are avoided. This is like saying that Internet Explorer is not insecure, as long as you visit the right web-sites.

                For most applications assembly is a worthless insecure language, and you should stick to a higher level language if you don't want to introduce problems (for anything larger, but probably including "hello world").
              • No offense, but give a fool a hammer and he'll crack his skull.

                Give a man a gun, and he can kill many people with it.

                Give that same man a pencil and... eh, not so much.
              • Re:Phew! (Score:5, Insightful)

                by ArbitraryConstant (763964) on Friday February 04, 2005 @11:28PM (#11579879) Homepage
                "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.
              • Re:Phew! (Score:5, Insightful)

                by timeOday (582209) on Friday February 04, 2005 @11:56PM (#11580053)
                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.
                No, the programmer is irrelevant to this argument. Pick any programmer you like, any one in the world. He will make mistakes at some rate. In C, those bugs will translate directly to security holes, whereas in a typesafe language they will not. It's just that simple.

                • Re:Phew! (Score:3, Insightful)

                  by jtshaw (398319)
                  It is true, any programmer, no matter how good, will make a mistake here and there. However, buffer overflows and such in a single program don't have to be the security nightmare that they often are these days.

                  It all comes down to bad OS design in general. Take the IE exploits for example. Why the heck can you get so much system access through an exploit in a web browser?!? Lets be honest here, the security model employed in most of today's OS's is mind boggling in it's ineptness.

                  Linux is not immune e
                • Re:Phew! (Score:3, Interesting)

                  by Brandybuck (704397)
                  All programming mistakes are security holes, because any software that doesn't behave as intended is a security hole. They might not all grant root access to random passerbys, but they are security holes nonetheless.

                  Anecdote time. After five years of working on a million+ line C/C++ codebase, I ran across my first buffer overflow last monday. I've seen many potential buffer overflows (and fixed them when I found them), but this was the first I've seen actually get thrown over the wall to QA.

                  If buffer over
                • by EventHorizon (41772) on Saturday February 05, 2005 @03:12AM (#11580873)
                  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.
                • Re:Phew! (Score:3, Insightful)

                  by tomstdenis (446163)
                  How did your post get insightful?

                  buffer overflows are not the only kind of bug that plagues development. quite a few "plain old logic errors" or "insecure designs" are source of problems.

                  I mean I just reinstalled pam last night [for the second day in a row... diff versions] with maybe 20 patches applied to it. I doubt all 20 [or any at all] were due to buffer overflows.

                  A proper programmer would do proper bounds checking on their own [e.g. I need to store N bytes, do I have N bytes available]. People w
              • Re:Phew! (Score:3, Insightful)

                by HiThere (15173) *
                Actually, C *is* inherrently insecure. You are required to use unbounded pointers. And, yes, assembly language is insecure in exactly the same way.

                It would help if C automatically initialized ram (and I've known at least one C that did, but it isn't a part of the language specs), just like it helps not to be able to use 0 as a pointer address. But the only thing that would make C safe would be to put it in a box, and not let it look outside. Even then you'd get buffer overflows within the code, but if
              • Re:Phew! (Score:5, Insightful)

                by jilles (20976) on Saturday February 05, 2005 @04:22AM (#11581076) Homepage
                ASSEMBLY is a totally inappropriate language for the vast majority of applications, including operating system kernels, video card drivers and games. The complexity and security tradeoff simply doesn't justify the performance gains. That's why it isn't used anymore in most of the software industry. The same is true to a lesser extent for C and C++.

                These languages are inherently insecure because they allow for mistakes that other languages do not allow for. Combine this with the fact that it doesn't take a fool to make mistakes and you have the perfect proof that C is inherently insecure. Refute either of those arguments and you might have a point.

                The problem with C is that it takes the inhuman capability to not make mistakes to end up with secure software. That's why all of the long lived C software projects have to be constantly patched to correct mistakes. Buffer overflows are no accidents, they are the predictable result of using C. Use C -> expect to deal with buffer overflows, memory leaks, etc. Every good C programmer knows this.

                The difference between good C software and bad C software is that in the latter case the programmers are surprised whereas in the first case the programmers actually do some testing and prevention (because they expect things to go wrong). Mozilla Firefox comes with a talkback component because the developers know that the software will crash sometimes and want to be able to do a post mortem. The software crashes because the implementation language of some components is C. IMHO mozilla firefox is good software because it crashes less than internet explorer and offers nice features.

                Of course we have learned to work around C's limitations. Using custom memory allocation routines, code verifiers and checkers, extensive code reviews we can actually build pretty stable C software. The only problem is that C programmers are extremely reluctant to let go of their bad habits. Some actually think they are gods when they sit down behind their editors and do such stupid things as using string manipulation functions everyone recommends to avoid like the plague, trying to outsmart garbage collecting memory allocaters by not using them, etc. If you'd build in a switch in the compiler which enforces the use of the improvements listed above, most of the popular C software simply wouldn't compile. But then it wouldn't be C anymore because the whole point of C is to allow the programmer to do all the bad things listed above, even accidentally.

                IMHO programmer reeducation is an inherently bad solution to inherent security problems of the C language. You can't teach people not to make mistakes. You need to actively prevent them from making mistakes. You can make mistakes in other languages but they are a subset of the mistakes you can make in C. Therefore you should use those languages rather than C unless you have a good reason not to. Any other reason than performance is not good enough.
              • Good architect will know how to choose tools to match the problem. (If you can't, either you are not educated or you are code slave)

                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

          • Re:Phew! (Score:3, Insightful)

            Fair enough, but how often does the kernel do things like parsing strings?
    • Re:Phew! (Score:3, Funny)

      by Lord Kano (13027)
      Good thing Linux isn't written in...

      What Visual Studio .NET? Yep. Good thing it isn't.

      LK
  • Advertisement? (Score:5, Insightful)

    by nuclear305 (674185) * on Friday February 04, 2005 @08:51PM (#11578840)
    I actually RTFA since it included a sensationalistic phrase like "biggest and most offensive mistakes that they could have made."

    To me, it sounded like a big advertisement for Java.

    It's the developers decision to use unsafe code in the .NET platform. I certainly wouldn't call this a huge mistake made by MS.

    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?

    • Re:Advertisement? (Score:2, Insightful)

      by haystor (102186)
      I'm just curious, but what language(s) of ultimate security is Java and Solaris written in?
    • Re:Advertisement? (Score:5, Insightful)

      by TWX (665546) on Friday February 04, 2005 @08:59PM (#11578914)
      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.
      • Re:Advertisement? (Score:5, Insightful)

        by n0-0p (325773) on Friday February 04, 2005 @09:14PM (#11579066)
        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.
        • Re:Advertisement? (Score:3, Interesting)

          by owlstead (636356)
          I agree with almost everything of your post. However, I must say that not every features .NET has over Java is an improvement. And not everything has such a long track record either. It took MS almost no time at all to implement almost every single feature of Java 1.5 into C#. Then again, Java added auto-boxing, which seems to stem from C#. None of the features of both languages is really original of course.

          Note that the Java VM of Microsoft was not that safe. I am very curious if .NET will have a better t
          • Re:Advertisement? (Score:3, Informative)

            by devinoni (13244)
            Other than generics, and static imports, all the new language features of Java 1.5 aka 5.0 were available in C# 1.0. There was even a slashdot story about it. http://it.slashdot.org/article.pl?sid=04/10/11/145 4220&tid=108&tid=8/ [slashdot.org]
        • Re:Advertisement? (Score:5, Interesting)

          by gburgyan (28359) on Saturday February 05, 2005 @12:06AM (#11580113) Homepage
          I have to agree -- and I'll try to extend your arguments even further.

          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.

        • Re:Advertisement? (Score:3, Informative)

          by DrXym (126579)
          The "integrating more cleanly" bit is worth more exploration. Java does allow native calls via JNI but it's always been bloody fiddly to get it to work. It does work, but it's fiddly requiring you define an interface, run a tool to generate stubs and implement those stubs handling exceptions & objects via a large set of JNI helper methods. Thus the average Java programmer doesn't even *think* about writing native code unless they absolutely, positively have to. So virtually every third party lib is pure
      • Re:Advertisement? (Score:5, Insightful)

        by Zeinfeld (263942) on Friday February 04, 2005 @09:42PM (#11579260) Homepage
        The problem here is that it will be very difficult to take Gosling seriously when he talks about anything in future. This does not make me think any better of Sun.

        Nobody is going to use C or C++ to write a completely new program under .NET. There are occasions where I might use C for something I wanted to make cross platform but no way would I ever go near C++.

        Most people who are going to use the new .NET support are people who have legacy C programs and want to gradually transition them to the .NET base in stages. The makes a good deal of sense.

        The other constituency is folk who are writing stuff that is almost but not quite at driver level.

      • C and C++ allow for buffer overflows.

        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

      • Re:Advertisement? (Score:3, Interesting)

        by andreyw (798182)
        C is a language. Its not an OS executive. It can't stop you from overwriting 0xdeadbeef with gobbledygook if your OS has no VMM.... which unless you're still running DOS, writing a kernel, or programming an embedded device... is not a problem as you might imagine.
    • Re:Advertisement? (Score:2, Insightful)

      by rackhamh (217889)
      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?

      DISCLAIMER: COMPLETELY OFF-TOPIC

      I don't know what the law is, but if a hunting rifle can only be legally used for hunting, this actually a pretty good idea. The card mechanism could also be used to enforce hunting seasons.

      I realize this offends some people's sense of rights, but I'm not particularly inclined to defend somebody's "right" to use a firearm outside its
      • Re:Advertisement? (Score:3, Insightful)

        by damiangerous (218679)
        I don't know what the law is

        Obviously.

        but if a hunting rifle can only be legally used for hunting

        A hunting license licenses the owner to take a certain type of game (deer season, etc) on certain land (assigned state land, private land, etc) during certain times (hunting seasons, obviously) with certain tools (shotgun only, bow, etc). It only grants this, in the case of firearms, to people who already legally own them. A "hunting rifle" is simply a subset of rifle suitable for a certain task (which var

    • Re:Advertisement? (Score:5, Insightful)

      by miu (626917) on Friday February 04, 2005 @09:07PM (#11578994) Homepage Journal
      I think he is talking about the fact that the type system of managed code itself could potentially be subverted by unmanaged code added by other developers.

      The article is heavy on sensationalism and short on content so it is difficult to tell what is actually being debated here, but I think that Gosling is claiming that support of C type handling in itself creates a chink in the armor of the CLR, regardless of any particular project's use of that feature.

      • Re:Advertisement? (Score:5, Insightful)

        by ndykman (659315) on Friday February 04, 2005 @11:59PM (#11580075)
        Not so. Well, unless you hacked the .Net type verification and loading code, managed to install it over the .Net Framework (not easy, really).

        All use of unsafe features in .Net are marked as such and can't be hidden. So, pointers, unsafe casts, etc. all stick out to the type loader. In fact, if an .Net assembly tries to mark itself as safe and it has unsafe features, the loader won't load it.

        As far as I know, there is no example of unmanaged code that can violate the managed code type system, and .Net was explicitly built to keep this from happening.

        Also, this ignores that C/C++ support is much more complicated in .Net. Yes, there is the IJW (It Just Works) stuff that allows unmodified code to compile to unsafe .Net assemblies, but there is also the C++/CLI stuff, which creates a CLS version of C++.

        Frankly, this seems like a bit of sour grapes to me. .Net does really improve on Java in lots of ways. Yes, James, Java isn't the last word on programming languages. .Net isn't either.
    • A few years ago a non-techie friend mentioned that he had read an interviewer with the creator of Java.

      Me: "Oh, that would be, umm, James Gosling."

      He: "No, that's not the name. It was a lady. Let me check ... Gina Centoni."

      Me "Who?"

      A web search revealed that Ms. Centoni's position was "Director of Java Marketing." Out of the mouths of babes come all wise sayings.
    • Re:Advertisement? (Score:3, Insightful)

      by iabervon (1971)
      His point is essentially that .NET does not protect the user against untrusted code, while Java does. If you run .NET code, you have to trust the developer, because the system won't protect you against a malicious or careless developer. If you run Java code in a sandbox, you're safe, because the system will watch what's going on and can be sure of the safety of its information.

      A hunting rifle is fine for some purposes, but decorating your house with them is unwise. Java, effectively, has support for making
      • Re:Advertisement? (Score:3, Informative)

        by cookd (72933)
        His point is essentially that .NET does not protect the user against untrusted code, while Java does. If you run .NET code, you have to trust the developer, because the system won't protect you against a malicious or careless developer. If you run Java code in a sandbox, you're safe, because the system will watch what's going on and can be sure of the safety of its information.

        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 .NET code in or out o
  • Woah (Score:5, Funny)

    by pHatidic (163975) on Friday February 04, 2005 @08:51PM (#11578851)
    CowboyNeal is defending Microsoft. Someone take a screengrab, Slashdot's been hacked!
  • by Anonymous Coward on Friday February 04, 2005 @08:52PM (#11578855)
    So you mean to tell me that the father of Java won't be slightly bias?

    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. .NET is great (for its target area)
    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.
    • by bitflip (49188)
      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.
  • by BlueCup (753410) on Friday February 04, 2005 @08:53PM (#11578859) Homepage Journal
    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.
  • What a surprise! (Score:5, Insightful)

    by Anonymous Coward on Friday February 04, 2005 @08:53PM (#11578861)
    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.

  • JNI (Score:3, Informative)

    by codepunk (167897) on Friday February 04, 2005 @08:53PM (#11578863)
    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.
    • Re:JNI (Score:5, Informative)

      by patniemeyer (444913) * <pat@pat.net> on Friday February 04, 2005 @09:16PM (#11579078) Homepage
      But JNI is not Java... It's an API. For that matter you might consider sockets and network connections to make Java unsafe because they could invoke unsafe applications.

      It is completely fair to point out that .NET allows you to choose safe vs. unsafe code... but it is a little different from the Java scenario in that this is unsafe code that is run through the VM. It's just an odd choice to make.

      Pat Niemeyer
      Author of Learning Java, O'Reilly & Associates
      • Re:JNI (Score:3, Insightful)

        by spideyct (250045)
        It may be fair to point out, but it is kinda silly without any context.

        Java lets you write to the user's filesystem. Does that make it insecure? You could run a program to wipe out your hard drive!

        But Java allows for a "sandbox". So does .NET. And if your code runs in that .NET "sandbox" (for example, if it is running from a network resource), it won't let you run unsafe code.
  • by Faust7 (314817) on Friday February 04, 2005 @08:53PM (#11578864) Homepage
    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.
  • by patniemeyer (444913) * <pat@pat.net> on Friday February 04, 2005 @08:54PM (#11578870) Homepage
    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.
    • You're wrong.

      The Microsoft CLR is also type-safe at the VM level. If you choose to use pointers in Managed C++, though, you lose any ability to assert heap access safety, and therefore must mark your code as unsafe, because you can perform pointer arithmetic.
    • by jeif1k (809151) on Friday February 04, 2005 @10:10PM (#11579459)
      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.
  • by Saint Stephen (19450) on Friday February 04, 2005 @08:54PM (#11578876) Homepage Journal
    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.
  • I did Read the Fine Article and didn't find anything in it worth mentioning. Nothing specific, or even elluded to. What a waste.
  • by apoplectic (711437) on Friday February 04, 2005 @08:58PM (#11578910)
    New languages such as C# and Visual Basic.NET only produce managed code.

    Hey, what about the keyword unsafe in C#? Sheesh.
  • by jerometremblay (513886) on Friday February 04, 2005 @08:58PM (#11578911) Homepage
    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?
  • by ahdeoz (714773)
    Gosling that Java is inherently insecure, as it is written in C.
  • A:
    In .NET you can write code that harms a computer and deletes files.
    B:
    In Java you can write code that harms a computer and deletes files.

    A:
    You can write code in C#, in which case it is managed and helps prevent you from making stupid mistakes.
    B:
    You can write code in Java in which case it is somewhat managed and helps prevent you from stupid mistakes.

    A:
    Under .NET you can write code in C++ (which very few folks developing for .net do) and you take the risk of stupid mistakes.
    B:
    Under Java you read Sun's doc
  • Rediculous (Score:2, Interesting)

    by SnprBoB86 (576143)
    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:
    A .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.

    For example: The end user can grant unsafe permissions to the Microsoft Managed Di
    • Re:Rediculous (Score:5, Insightful)

      by janoc (699997) on Friday February 04, 2005 @09:29PM (#11579181)
      Yeah, right - the same problem as with signed ActiveX - once a buffer overflow in the trusted code is found, your security is a fair game - the attacker has to only persuade e.g. your browser to load the buggy but trusted code. The managed languages like C# and Java were invented exactly with the purpose to prevent this kind of holes.

      To me this looks like a similar problem as allowing running native code via ActiveX. Yeah, we have permissions, signing and what ever - how much does it take for a trusted but buggy ActiveX applet to be exploited?

      Huge mistake, IMHO. And do not compare this to JNI - I am no Java expert, but AFAIK you simply cannot call JNI functions from something like web applet by design, whereas here it is on the discretion of the app developer.

  • Why oh why (Score:4, Insightful)

    by Anonymous Coward on Friday February 04, 2005 @09:03PM (#11578947)
    When elevators were first invented, people didn't want to use them because people thought they were not safe. They were right. Elevators were not safe. When Mr. Otis invented the safety elevator, which had a catch so that it would not fall even if the cable were cut, people started using elevators. It would be foolish to trust your life to an elevator without such a safety system. You could use it to lift bales of hay or cement powder or something but you wouldn't put a human being in it.

    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.

    • Re:Why oh why (Score:3, Informative)

      by omicronish (750174)

      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

  • by Stevyn (691306) on Friday February 04, 2005 @09:10PM (#11579016)
    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
  • Beware the agenda (Score:4, Interesting)

    by BillsPetMonkey (654200) on Friday February 04, 2005 @09:14PM (#11579057)
    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.

    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 .NET and the unsafe keyword for managed code are there to restrict how you use native objects.

    What Gosling is really criticising is the way .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.
  • by frovingslosh (582462) on Friday February 04, 2005 @09:33PM (#11579204)
    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 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.

  • by 1nv4d3r (642775) on Saturday February 05, 2005 @01:04AM (#11580383)
    I guess that's why there's no java native interf...

    oh. nevermind.
  • by rabtech (223758) on Saturday February 05, 2005 @01:32AM (#11580501) Homepage
    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.
  • by Earlybird (56426) <slashdot@pure3.14159fiction.net minus pi> on Saturday February 05, 2005 @01:50AM (#11580574) Homepage
    • 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.

    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:

    • Has direct access to every part of the operating system and executes instructions directly from memory. This means that malicious code can slip into its memory space through buffer overflow exploitations and the like.
    • Is, in almost all cases/operating systems, running with the same capabilities as the logged-in user, which means it has virtually endless power that ranges from formatting your hard drive to infecting other nodes with worms or looking through your email app's address book. It's not limited to the desktop computer of the hapless Windows user, either: Unix daemons running on servers as non-root users can cause serious havoc.

    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.

  • by SimHacker (180785) on Saturday February 05, 2005 @02:09AM (#11580667) Homepage Journal
    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
  • by DavidHopwood (853221) on Sunday February 06, 2005 @01:38AM (#11587995)
    .NET and Java are both insecure, because they both rely on too much code written in unsafe languages.

    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 .NET and Java allow any arbitrary application to load unsafe code.

    So basically, Gosling's argument is correct: .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.

"Irrationality is the square root of all evil" -- Douglas Hofstadter

Working...