Slashdot Mirror

← Back to Stories (view on slashdot.org)

Don Box: Huge Security Holes in Solaris, JVM

Posted by timothy on from the so-this-pot-and-kettle-are-in-a-coal-mine-at-night dept.

DaHat writes "Don Box, one of the authors of the original SOAP specification in 1998, now an architect on Microsoft's next generation Indigo platform recently responded to James Gosling's remarks regarding huge security holes within the .NET Common Language Runtime (CLR). Don argues that the same 'flaws' that Gosling noted in the .NET CLR exist both within the Solaris operating system as well as the JVM, both of which support execution of C and C++ code, as well as explaining why this is not necessarily a bad thing."

2 of 226 comments (clear)

  1. I don't think anyone really read what Gosling said by Anonymous Coward · · Score: 5, Interesting

    Are we just going to have this continuing debate in which every side is inaccurately reduced to one slashdot-blurb-sized sound bite?

    Anyway, JNI doesn't need to be a security hole of the sort Mr. Box mentions; one can concieve of a Java VM which disallows unsafe JNI code from touching the memory of the bytecode-verified safe code, by partitioning JNI execution into a separate process. In fact at least one such JVM implementation exists already.

  2. Neither is really a security hole.... by Jaime2 · · Score: 5, Interesting

    Let's take a look at how each technology can become a security hole: By remote execution of content presumed to be in a "sandbox".

    .NET: Since unmanaged code is turned off by default for remotely loaded code, it will not be run by an unexpected trip to a web page.
    Java: Since JNI won't work by default under the same circumstances, the newest virus won't be injected into your system by an evil web page.

    Anything else is simply an architectural choice. MS likes to preserve compatibility while allowing you to move forward as quickly as posible. Sun wants you to rewite stuff in Java (for the most part), so the new stuff is more secure, but there will be more old stuff floating around that is still unsecure because we won't yet have found time to port it.

    BTW, Code Access Security in .NET is sophisticated enough to allow some apps to use unmange code, but not others, or some users, or software from a certain publisher, and a bunch of other options as well. You don't have to simply "turn on unmanaged code". They even have a simply way to allow software publishers to communicate these settings to customers instead of letting Joe Blow admin decide to simply turn off security to make it work.

    In summary, both technologies allow you to blow your own foot off if you aim the gun properly and squeeze the trigger. So what -- we were allowed to do that before these technologies came along and preventing you from being able to blow your own foot off will only slow adoption and cause more feet to be blown off.