×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Don Box: Huge Security Holes in Solaris, JVM

timothy posted more than 9 years ago | from the so-this-pot-and-kettle-are-in-a-coal-mine-at-night dept.

Security 226

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

226 comments

On Defense (2, Funny)

fembots (753724) | more than 9 years ago | (#11599689)

First instance of Microsoft mehing FUD?

Next up, Notepad will be the target since it allows any malicious code to be written on it.

Re:On Defense (1)

goofyspouse (817551) | more than 9 years ago | (#11600417)

Help an old man out...WTF were you trying to say?

The word you've entered isn't in the dictionary. Click on a spelling suggestion below or try again using the search box to the right.

Suggestions for mehing:

1. meting
2. meshing
3. meeting
4. mating
5. mahonia
6. matting
7. Meeting
8. mewing

first (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11599696)

first

JNI is an API, not a platform... (4, Informative)

patniemeyer (444913) | more than 9 years ago | (#11599698)

Solaris - yes, it's unsafe. That's why my Solaris machine gets attacked if I don't have a firewall in front of it for ten seconds.

JVM - no, that's safe. JNI is an API, not a platform. For that matter you can say that any language which uses sockets for network programming or can write a file is unsafe. Not to mention that normal programmers never use JNI... It's a very low level integration API.

Don's comments did not really add anything that wasn't covered in the Slashdot discussion.

Pat Niemeyer
Author of Learning Java, O'Reilly & Associates

Re:JNI is an API, not a platform... (1, Insightful)

Anonymous Coward | more than 9 years ago | (#11599712)

Solaris - yes, it's unsafe. That's why my Solaris machine gets attacked if I don't have a firewall in front of it for ten seconds.

Really? Who the hell writes worms for such an obscure platform?

Re:JNI is an API, not a platform... (0)

Anonymous Coward | more than 9 years ago | (#11599800)

The same guys who keep writing worms for IIS.

Remember, IIS has a much smaller installed base than Apache, yet IIS still has orders of magnitude more security holes than Apache.

Re:JNI is an API, not a platform... (4, Interesting)

squiggleslash (241428) | more than 9 years ago | (#11600009)

IIS has orders of magnitude more worms and viruses than Apache, not security holes. (If you know different, please report all these security holes to the respective developers.)

In any case, that's not why IIS is a target. IIS is a target for a number of reasons:

1. The default web server (once you installed the Option pack) on NT4 was a version of IIS that had a couple of security holes.

2. IIS is almost certainly more popular than Apache on Windows-type servers. Yes, Apache runs on it too, but there's a mentality that goes with Microsoft products. With Windows being the most "popular" (well, most installed) operating system in existance, you'd expect it to be the home for most virus writers, and virus writers aren't going to want to write for platforms they consider obscure.

3. IIS always runs on Windows which almost always has the same CPU architecture (ie ix86) and APIs. Apache can run on a variety of platforms. Exploiting, for example, buffer overflows, is relatively difficult if you don't know the architecture, or even something as simple as how you can make system calls.

4. People hate Microsoft. Most people's views of Apache and similar systems are neutral at worst. I've never met or talked to anyone who hates Apache.

5. One serious hole is enough. Both Apache and IIS have suffered these in the past and probably will do in future (well, until Gosling rewrites Apache in Java ;-)

IIS is usually used as the proof to counter the argument that marketshare matters when viruses are written. I think this is always a bogus argument: IIS's marketshare is enough (it's not like writing a virus for GNU/Linux), and IIS is tied to an operating system that is the most installed in the world. It's fair to say it's the exception that, quite literally, proves the rule.

Re:JNI is an API, not a platform... (0)

Anonymous Coward | more than 9 years ago | (#11600413)

I dunno, I hate Apache. I've programmed/set up/managed both IIS and Apache over the past 8 years, and Apache is primative in comparison.

Error checking the conf file? No way, just dump core!

Log files getting too big? Don't worry, we'll just stop processing your webserver requests!

Oh the joy, you people must truly be masochists.

Apologetics (1, Interesting)

Anonymous Coward | more than 9 years ago | (#11600454)

5. One serious hole is enough. Both Apache and IIS have suffered these in the past and probably will do in future (well, until Gosling rewrites Apache in Java ;-)

When you see the first Apache-based worm which has 15 different potential attack vectors-- which nimda did-- you may make this argument. Not until then. Yes, one vulnerability may be all you need. But the others, ah, certainly help, especially considering that the more critical vulnerabilities are out there, the less likely all extant installations have patched them all.

I also find it very wierd that you try to use both "virus writers use microsoft products" and "virus writers hate microsoft" as excuses for IIS's worm problem. Wouldn't there be a slight problem with those two overlapping?

Aside from this, believe it or not, worms are not the only thing out there which make use of security exploits, and the other things don't fall prey to the situations you describe. IIS's poor security track record did not begin with the worm problem. the worm problem just threw it into such sharp relief it could no longer be ignored.

Re:Apologetics (0)

Anonymous Coward | more than 9 years ago | (#11600522)

I also find it very wierd that you try to use both "virus writers use microsoft products" and "virus writers hate microsoft" as excuses for IIS's worm problem. Wouldn't there be a slight problem with those two overlapping?

You're new here, aren't you?

We all hate Microsoft, but we all use Windows. We all hate the MPAA and the RIAA, but we like the movies and music they produce. (This is for small values of "all".)

In some cases it is a misguided hate, and we actually like their products (but love to complain about them). In some cases it is the result of monopoly power and we have no choice (which makes the hate stronger). In some cases it is about being good professionals, and we can say exactly why we hate them because we have evaluated them repeatedly.

Generally, rather than not use those products, we just obtain them illegally. That's stickin' it to the man!

Re:Apologetics (0)

Anonymous Coward | more than 9 years ago | (#11600558)

We all hate Microsoft, but we all use Windows. We all hate the MPAA and the RIAA, but we like the movies and music they produce. (This is for small values of "all".)

Is that so?

In that case, may I venture to hypothesize that perhaps squiggleslash's assertion that virus writers both hate Microsoft and use their products is not actually based on any evidence or real-world knowlege, but simple projection as a slashdotter-- expecting that since some slashdot.org readers feel this way, so must "virus writers"?

Re:Apologetics (1)

squiggleslash (241428) | more than 9 years ago | (#11600676)

First, let me say I think the GP hit the nail on the head.

Second, I project real life. Virus writers are, given the MASSIVE market share of Windows, likely to be Windows users themselves.

And generally, most people I know, regardless of whether they're geeks or not, are not especially fond of Microsoft. Most are neutral, many dislike them. They dislike Microsoft because they use Windows.

And geeks, in my experience - which naturally is going to include most virus writers - are especially negative towards Microsoft.

No, I don't know any virus writers personally, but I'd have to be blind not to notice the way the world is.

Re:JNI is an API, not a platform... (0)

Anonymous Coward | more than 9 years ago | (#11600509)

Actually windows boxes run about 20% of the servers out there. Where as apache runs on 70%.

Source: http://news.netcraft.com/archives/web_server_surve y.html [netcraft.com]

But hey whats the truth when you are spouting compnay FUD.

Re:JNI is an API, not a platform... (0)

Anonymous Coward | more than 9 years ago | (#11600626)

Sorry, but I must have missed the part where I said anything that contradicted that.

Re:JNI is an API, not a platform... (0)

Anonymous Coward | more than 9 years ago | (#11599807)

What do you mean "obscure platform"? Sun customers both feel they deserve to have the bugs fixed!

Re:JNI is an API, not a platform... (3, Informative)

Rinikusu (28164) | more than 9 years ago | (#11599748)

Isn't JNI basically what you use when you want to write a "java native" driver for your custom hardware (I'm thinking x10 and what not)? (But then you'd have to port the JNI to every platform you wanted to support, right?)

Re:JNI is an API, not a platform... (3, Informative)

essiescreet (553257) | more than 9 years ago | (#11599806)

Yes, this is corrrect. The jni allows you to declare "native" methods for Java. This allows you to do stuff like connect to shared memory, process UNIX signals, and do other low-level operations that are platform specific.

So, you do have to port it, but it's there if you really, really need to do something in C that you can't do in Java.

As for normal programmers not using it, that's not true. I use the JNI for integrating java with a large software package that's written in C, and runs on AIX or Linux. I'm a regular programmer. It's really not that difficult, just a little different.

In my case, it's allowed me to write Java add on's to a system that's written in C. This makes the delopment faster, the GUI's prettier, and the interface is the only C code to manage.

Re:JNI is an API, not a platform... (0)

Anonymous Coward | more than 9 years ago | (#11599829)

There are more applications than just hardware drivers. Sun's own Java3D uses JNI, as do various other applications that utilize opengl libraries. In fact, I see lots more JNI stuff that is simply a wrapper around a C/C++ library that I do anything else. Then there's stuff like MATLAB that doesn't want the vital proprietary parts of the code available as .class files, so they use JNI to interface with their Java gui stuff. It has tons of good uses.

Re:JNI is an API, not a platform... (4, Informative)

patniemeyer (444913) | more than 9 years ago | (#11599892)

First, technically there's no reason you couldn't build an API allowing pure Java hardware drivers. Sun did it for JavaOS (which apparently went nowhere, but for other reasons). I wish someone would take this idea and port it to Linux, giving us pure Java device drivers.

But in answer to your question - yes, you can use JNI to talk to unsupported hardware by invoking native routines and, internally, the Java libraries use it to invoke native code on the platform for basic services like talking to the filesystem, sockets, or anything that's not written in pure Java.

Many people might be surprised though to know just how much of Java is written *in Java*... The vast majority of the APIs are pure Java code. Only the lowest level stuff is delegated to platform specific code. For example, Java does DNS and most crypto in pure Java.

And finally, most X10 hardware uses a serial API... I have one controlled by Java... also a network of Dallas Seminconductor sensor devices controlled by Java.

Pat Niemeyer
Author of Learning Java, O'Reilly & Associates

Re:JNI is an API, not a platform... (2, Informative)

MoebiusStreet (709659) | more than 9 years ago | (#11600268)

The vast majority of the APIs are pure Java code.

RTFA:

In looking at the Indigo code base (which was 1123 C# files as of early last week), only 19 of them use the unsafe keyword.

Why in the world would one consider the *possibility* of unsafe code in the CLR a security hole? Sure, you can call the use of unsafe a hole. But if (like virtually all .Net developers I know) you never use that, then there's no issue at all.

Is Gosling complaining that the CLR is so flexible that someone with extraordinary needs *can* use unsafe when necessary?

Re:JNI is an API, not a platform... (1, Troll)

myowntrueself (607117) | more than 9 years ago | (#11600306)

"giving us pure Java device drivers."

I'm sorry, but that just sounds like a joke...

I'm not sure though, are you being serious?

Re:JNI is an API, not a platform... (1)

jeif1k (809151) | more than 9 years ago | (#11600317)

First, technically there's no reason you couldn't build an API allowing pure Java hardware drivers.

You are confusing "purity", "safety", and "security"; if you did what you suggest, you would indeed be writing drivers in "pure Java", but if those APIs were accessible, they would undermine safety.

Re:JNI is an API, not a platform... (3, Interesting)

Anonymous Coward | more than 9 years ago | (#11599808)

For that matter you can say that any language which uses sockets for network programming or can write a file is unsafe.

Actually, yes that is a true statement which is why the .NET CLR allows you to tweak that out and explicitly deny those rights. (By default these rights are denied for applications running on a remote store.) And, as Don Box said, the unsafe keyword is not meant for daily consumption. To paraphrase, "normal programmers never use the unsafe keyword. It's a very low level integration API."

Re:JNI is an API, not a platform... (1)

patniemeyer (444913) | more than 9 years ago | (#11599952)

the unsafe keyword is not meant for daily consumption.

Wait... I don't know the answer to this, but - won't all C/C++ code running on .NET be tagged as unsafe? Or is the programmer expected to tag every pointer cast or dereference explicitly?

Normal programmers do use C/C++ daily... and it is unsafe. I think the point vs. JNI is valid.

Pat Niemeyer

Re:JNI is an API, not a platform... (0)

Anonymous Coward | more than 9 years ago | (#11600020)

You don't tag the C/C++ code, you tag the C# class that is using the C/C++ code.

Now, there is Managed C++ and if you are using that to create dotNet classes, you only need to mark it unsafe when you are doing something that is, well, unsafe. :) You can either tag an individual method, or you can tag the class, or you can tag the entire assembly as unsafe. The caller can determine if it wants to execute your assembly. This permission bubbles all the way up to the machine configuration. So if you explictly denied all apps the right to run unsafe code, your assembly will not be allowed to run. Sounds secure to me.

It's clear that you understand JNI, but equally clear that you're missing the facts when it comes to the .Net security model. Since Box knows 'em both, I'll defer to him.

Re:JNI is an API, not a platform... (2, Informative)

YU Nicks NE Way (129084) | more than 9 years ago | (#11600078)

Managed C++ is type and bounds safe. Unsafe C# and/or C++ allow type inference, but not bounds checking, and therefore allow a major class of exploits that aren't possible within the standard portions of the dialects. A call into C/C++ from within CLR requires PInvoke, just as a call into C/C++ from Java requires JNI.

Normal programmers writing in C#/Managed C++ use C/C++ less frequently than "normal" Java programmers do, actually, because they have access to the intermediate "unsafe" calls, through which most perf sensitive enumerations can be run without moving "down to the metal".

Basically, Gosling said it, and you fell for it. In /.-speak, they say "YHBT, YHL, HAND."

Re:JNI is an API, not a platform... (2, Interesting)

Scorillo47 (752445) | more than 9 years ago | (#11599924)

And a similar blog entry here:

http://blogs.msdn.com/adioltean/archive/2005/02/ 07 /368226.aspx

I am reading now an article in which James Gosling claims that .NET has a huge security hole. The problem seems to be that .NET allows execution of both safe and unsafe managed code in the same process:

[...], Gosling is concerned about "unsafe" code, which is produced by traditional languages like C and C++. Unsafe code is old code that does not strictly follow the rules of type safety that .NET defines, and this sort of code requires additional permissions to execute. According to Sterling, "you as a developer take it upon yourself" to utilise unsafe code in your .NET applications.

But what James Gosling fails to mention is that the Java runtime also allows the same type of unsafe code execution in every process running safe Java code. No, I'm not smoking crack. The technology is well established in the Java world and it is called JNI. Here is a quote:

The JNI allows Java code that runs within a Java Virtual Machine (VM) to operate with applications and libraries written in other languages, such as C, C++, and assembly. In addition, the Invocation API allows you to embed the Java Virtual Machine into your native applications.

Programmers use the JNI to write native methods to handle those situations when an application cannot be written entirely in the Java programming language. For example, you may need to use native methods and the JNI in the following situations:

The standard Java class library may not support the platform-dependent features needed by your application.
You may already have a library or application written in another programming language and you wish to make it accessible to Java applications.
You may want to implement a small portion of time-critical code in a lower-level programming language, such as assembly, and then have your Java application call these functions.
Think of it a second - in fact, how does a small Java program interoperate with the underlying operating system? How does a "Hello world" Java program succeed to write anything to the console? After all, the Win32 API is not directly callable from Java, correct?

Therefore, by its own measure, Gosling only suceeded to demonstrate that Java also contains a huge security hole... :-)

P.S. And, please, don't tell me that JNI is not a security hole because writing JNI code is eventually harder and not done as often than using "unsafe" in C#... Face it - in Java, whenever you are writing to a file, communicating through a network interface or just handling GUI controls, there is always some unmanaged C++ code being executed in your process...

Re:JNI is an API, not a platform... (3, Insightful)

patniemeyer (444913) | more than 9 years ago | (#11600102)

Face it - in Java, whenever you are writing to a file, communicating through a network interface or just handling GUI controls, there is always some unmanaged C++ code being executed in your process...

Of course... and Java executes RISC instructions that could reveal flaws in the processor design too... but those levels were not written in the course of daily programming. The native drivers in Java are very small (e.g. all of Swing is built on a few AWT calls for opening windows and doing primitive drawing). And those routines presumably get a lot of scrutiny for all kinds of reasons - security being one and performance being another. I have never heard of a common security problem like a buffer overflow in the native libs shipped with Java... It's going to happen someday of course and that's why people created Java and managed code. To minimize the exposure of those regions.

The futher up the food chain your code goes the more protected it is and the harder it becomes to exploit low level security holes. It's analogous to the way in which you (used to?) gain confidence in the GNU C compiler by having it compile itself and then using the 2nd gen to compile a third... At each step the possibility of simple problems become much more abstract and harder to exploit.

Pat Niemeyer
Author of Learning Java, O'Reilly & Associates

Re:JNI is an API, not a platform... (1)

Marthisdil (606679) | more than 9 years ago | (#11600323)

but those levels were not written in the course of daily programming.

And neither are the exploits people write to take advantage of "flaws"

Re:JNI is an API, not a platform... (0, Flamebait)

jeif1k (809151) | more than 9 years ago | (#11600388)

It's going to happen someday of course and that's why people created Java and managed code. To minimize the exposure of those regions.

You seem to be blissfully unaware of about half a century of computing history: safe, managed code used to be common in high-level language. The people who created Java no more created it than they created integer addition. The Java language is about where programming languages were in the late 1960's/early 1970's.

The real question to ask is how in the world unsafe languages like C and C++ ever managed to succeed, and why something as poorly designed as Java ended up catching on when there have been far better languages with the same kind of safety guarantees around for decades.

But, perhaps, the answer is simply that people like you write the books that people get their information from. The blind leading the blind, it seems.

Pat, Pat, Pat (-1, Flamebait)

I judge you (796415) | more than 9 years ago | (#11600004)

Last story, I thought you were just ignorant and talking out of your ass.

However, it's now apparent that you are actually just a Java shill and uninterested in factual technical discussion.

Thank you for clarifying the situation.

Re:JNI is an API, not a platform... (4, Insightful)

jeif1k (809151) | more than 9 years ago | (#11600158)

JVM - no, that's safe. JNI is an API, not a platform.

You can look at C# as two languages: an "unsafe" and a "safe" language. The safe language is the equivalent of Java. The "unsafe" language is the equivalent of C or C++ linked in through JNI. Linking "unsafe" to "safe" code in C# has the same restrictions on it as does linking native code to pure Java code in Java. So, Gosling's rantings have no technical merit.

However, the C# solution is better than the Java solution: unsafe code in C# still contains substantially more error checking than equivalent C code linked through JNI, you generally need much less unsafe code in C# than in Java to accomplish the same task, and C# unsafe code doesn't need to be recompiled for different platforms and can just be distributed like other C# code.

Don's comments did not really add anything that wasn't covered in the Slashdot discussion.

What do you want? He is responding to an enormously stupid, self-serving comment from Gosling. You have to be clear and keep things simple in order to reach the kind of people who would swallow Gosling's nonsense in the first place.

Re:JNI is an API, not a platform... (0)

Anonymous Coward | more than 9 years ago | (#11600354)

He is responding to an enormously stupid, self-serving comment from Gosling.

Or rather, Gosling was pointing out an inherent advantage of Java that was one of the primary design goals of Java, but which .NET does not concern itself with. Then Don Box said he doesn't think it's an advantage. Then you agreed that you don't think it's an advantage.

But that doesn't make the advantage go away. It just means that neither you, nor Don Box, are interested in it.

Re:JNI is an API, not a platform... (1, Interesting)

Screaming Lunatic (526975) | more than 9 years ago | (#11600215)

Not to mention that normal programmers never use JNI... It's a very low level integration API.

And that's why a whole class of software is not written in Java. Get out of your web services, connect to database world.

At my previous position, we had a volume renderer that was written in C++, an SDK on top of the volume renderer that was written in managed C++, and applications were written in C#, VB.NET and Python.NET.

The right tool for the right job.

Using JNI would have been a pain in the eff-ing ass. Java is not low-level enough to be a high-performance systems programming language, and not high-level enough to be a scripting langauge. Hence, a good choice for web services but not the best choice for anything else.

Re:JNI is an API, not a platform... (1)

owlstead (636356) | more than 9 years ago | (#11600429)

Actually, when using BSH, it's pretty fun to use it (Java) as a scripting language, and it certainly beats the hell out of JavaScript (or python, but that's just my less te opinion). The JNI interface is pretty simple, but you would have to put it in place of the managed C++ SDK.

Now if they would only intergrate BSH into Eclipse so you can have completion etc. etc. as well.

You can't be serious (0)

Anonymous Coward | more than 9 years ago | (#11600457)

"Get out of your web services, connect to database world."

Dude. Maybe I'm misunderstanding you, but you use JDBC, and if you use a real J2EE implementation, the virtual machine handles that portion as well.

Java and Solaris are an order of magnitude safer than .NET. Only somebody with an agenda thinks otherwise.

sad news michael sims dead at 13 (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11599701)

I just heard some sad news on Communist talk radio - Slashdot "editor"/Domain hijacker Michael Sims was found dead in his cardboard box this morning. There weren't any more details. I'm sure nobody in the Slashdot community will miss him - even if you didn't enjoy his abuse of power, there's no denying his contributions to douchebaggery. Truly a filthy hippie.

Flaws aren't a bad thing? (2, Funny)

MattyDK23 (819057) | more than 9 years ago | (#11599707)

I can see it now..."Bugs deserve rights too!"

Trademark lawsuit? (0)

Anonymous Coward | more than 9 years ago | (#11599750)

MS calls it "Indigo"...

Do I smell a lawsuit from SGI?

Re:Flaws aren't a bad thing? (5, Funny)

Rosco P. Coltrane (209368) | more than 9 years ago | (#11599765)

I can see it now..."Bugs deserve rights too!"

Well, ask the original bug [faqs.org] at NSWC if it enjoys being taped to a cardboard note since 1947...

Re:Flaws aren't a bad thing? (1)

smitty_one_each (243267) | more than 9 years ago | (#11599904)

Boss Hogg says to "get yo' fax straight", Roscoe :)
[There has been a widespread myth that the original bug was moved to the Smithsonian, and an earlier version of this entry so asserted. A correspondent who thought to check discovered that the bug was not there. While investigating this in late 1990, your editor discovered that the NSWC still had the bug, but had unsuccessfully tried to get the Smithsonian to accept it -- and that the present curator of their History of American Technology Museum didn't know this and agreed that it would make a worthwhile exhibit. It was moved to the Smithsonian in mid-1991, but due to space and money constraints was not actually exhibited for years afterwards. Thus, the process of investigating the original-computer-bug bug fixed it in an entirely unexpected way, by making the myth true! --ESR]
However, if the NSWC in question is actually Dahlgren [navy.mil], the attention of the gun nuts in the crowd is drawn to the 18.1 inch gun down there on the firing line. Nothing above 16 inches was ever deployed in a US Naval gun, but it makes a swell trivia question.

Re:Flaws aren't a bad thing? (0)

Anonymous Coward | more than 9 years ago | (#11600088)

Say, you wouldn't know a joke if it painted itself dayglo-yellow, wore a silly hat and shouted "I'm a joke" at ya would you?

Lighten up for chrissake...

What do these both have incommon? (0, Redundant)

drakethegreat (832715) | more than 9 years ago | (#11599714)

They are both systems that are closed source (Well Solaris is now debatable) and both are managed by corporations. We all know how that affects security.

Re:What do these both have incommon? (0)

Anonymous Coward | more than 9 years ago | (#11599795)

What a crock... You actually think that open source is inherently secure because it isn't managed by a corporation?

All you have to do to blow your hypothesis out of the water is to look at the history of Linux and some of the apps running on it to see a long string of security holes. OSS gets patched just like CSS.

Re:What do these both have incommon? (4, Informative)

javatips (66293) | more than 9 years ago | (#11600097)

Java source code is available [sun.com] with little effort. So if you want to check it out and do some security analysis, you can do it.

I don't think anyone really read what Gosling said (5, Interesting)

Anonymous Coward | more than 9 years ago | (#11599752)

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. [sun.com]

Re:I don't think anyone really read what Gosling s (1)

de1orean (851146) | more than 9 years ago | (#11599968)

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

You mean there's another alternative? I don't follow.

Re:I don't think anyone really read what Gosling s (1)

X (1235) | more than 9 years ago | (#11600610)

A brilliant point... except that a) the real problem isn't the JNI code messing with the VM, and b) you can do the same thing with .NET.

It's that darn C and C++ code again.. (0, Redundant)

scenestar (828656) | more than 9 years ago | (#11599758)

Seems like most current holes come from the use of C and C++ code.

Arent there any safer alternatives?

Re:It's that darn C and C++ code again.. (2, Funny)

SnarfQuest (469614) | more than 9 years ago | (#11599934)

Intercal! It's very hard to write viruses using it.

(It's very hard to write anything else in it either)

This proves Python, Perl, and other FOSS==secure (1, Funny)

Anonymous Coward | more than 9 years ago | (#11599770)

Since Java and .NET are both so insecure; by subtraction, F/OSS is the most secure stuff around!

But that's where you're wrong-- Inline.pm! (1, Funny)

Anonymous Coward | more than 9 years ago | (#11599910)

But Perl and Python have the same security flaw we are discussing with regards to .NET and Java-- both allow linking against unsafe compiled code!

So the only really safe language to be using, in truth, is HQ9+ [biffle.org]. Rather than leaving the opportunity for error as Perl, Python, Java and .NET do, HQ9+ utilizes an innovative language design which ensures by the very syntax of the language that security violations are not possible. Consider using HQ9+ for your next enterprise application development project.

here we go again.... (5, Funny)

kevinx (790831) | more than 9 years ago | (#11599773)

is this one of those, "your hole is bigger than mine" arguments?

Re:here we go again....size doesn't matter (0)

Anonymous Coward | more than 9 years ago | (#11599932)

Size doesn't matter, It's how you use it.

(sorry)

All bloatware is buggy and risky. (1)

plinius (714075) | more than 9 years ago | (#11599791)

It is in the very nature of bloated software that its complexity increases faster than the number of source lines, and that the vulnerabilities and bugs increase perhaps even faster than that.

a tiny shot fired across the bow of bloatism [comcast.net]

Re:All bloatware is buggy and risky. (1)

gnuman99 (746007) | more than 9 years ago | (#11600377)

a tiny shot fired across the bow of bloatism

Oh, putting the UI in the kernel, are we? I think people just don't learn from mistakes of Windows...

Buggy X is one thing, buggy kernel is another.

I pity the lowly driverophobe (1)

plinius (714075) | more than 9 years ago | (#11600701)

If you're so afraid of drivers, perhaps you should remove your keyboard driver, and save us all from your false wisdom. A poem for you: He fears heresy Would never put GUI in there Repeats tired cliches

FUD (5, Informative)

micromuncher (171881) | more than 9 years ago | (#11599792)

To use JNI inside of an applet, it needs to be signed with the DLL/shared library pre-installed in lib. So, the topic of "Huge Security Hole in Solaris and JVM" is alarmist and FUD, considering that to get outside of the sandbox, you need to jump through serious configuration hoops.

Re:FUD (2, Informative)

Anonymous Coward | more than 9 years ago | (#11599834)

You can't use Unsafe/PInvoke inside a .Net hosted control (applet) unless permissions have been explicitly granted beforehand.

So to get outside that sandbox, you need to jump through configuration hoops.

the FUD comes from Gosling (2, Insightful)

jeif1k (809151) | more than 9 years ago | (#11600213)

To use JNI inside of an applet, it needs to be signed with the DLL/shared library pre-installed in lib.

And the equivalent is true for C# "unsafe" code: there are restrictions on where it can be run from and what can run it.

So, the topic of "Huge Security Hole in Solaris and JVM" is alarmist and FUD, considering that to get outside of the sandbox, you need to jump through serious configuration hoops.

The FUD is the nonsense Gosling was spewing about C#. Box is responding with hyperbole (he says so explicitly) to demonstrate how absurd Gosling's argument is.

Unfortunately, creating FUD seems to be a major occupation at Sun these days, and the targets are Sun's biggest competitors: Microsoft and Linux.

Re:FUD (0)

Anonymous Coward | more than 9 years ago | (#11600277)

... and that is *exactly* what you must do if you want to run .NET code with "unsafe" tag.

Babies... (1)

JossiRossi (840900) | more than 9 years ago | (#11599815)

Well sure, "Mr. Righteous" Yes, My Baby is bleeding. And sure I refuse to bandage her. But you know what, your baby is bleeding too so you can shut up, it's not that bad. Jerk.

This just in! (5, Funny)

kiwidefunkt (855968) | more than 9 years ago | (#11599842)

This just in: Programming languages are insecure. They allow third parties to run arbitrary code on your processor.

Microsoft will be releasing a patch which fixes this problem soon. Stay tuned.

Re:This just in! (1)

jimicus (737525) | more than 9 years ago | (#11600328)

Microsoft will be releasing a patch which fixes this problem soon.

I thought they already this ages ago - it was called Internet Explorer 4.

Yawn! (2, Insightful)

Z00L00K (682162) | more than 9 years ago | (#11599885)

This seems to be a shit-throwing contest more than actually trying to figure out means to manage security issues in platforms.

Programs will have bugs, regardless of what programming language that is used, since it always comes down to machine-code or even microcode in the end, and it's not easy to test a large software package for all possible permutations.

The only way around this problem is a layered security approach, which means that breaking one layer will not cause any critical effects. Unfortunately Microsoft has only recently recognized this and are applying patches on and off. Solaris and most *NIX:es are a little better off, but there are a lot of work to do for all operating systems here!

Inaccurate comparison (1, Informative)

shlong (121504) | more than 9 years ago | (#11599967)

Saying that the JNI exposes Java to the same C/C++ flaws as .NET/CLR is techinically true, but not very accurate. JNI was added to Java purely to allow the JVM to operate as a browser plugin. It wasn't something that Sun really liked or wanted to do since they really wanted Java to be a better, safer, and portable language. I think that this point was even discussed in some of the early books on JNI.

Microsoft, however, is actively looking to extend the CLR with a JNI-like interface. Why? To make it easier for people to port their legacy C/C++ apps to .NET. If you can keep most of your exsiting codebase untouched and just write .NET wrappers to access it, porting is theoretically easier. Microsoft doesn't care about platform portability (or safety, for that matter), they just want an easy way to get faster adoption.

Looking back at Java, JNI calls are hardly ever used. There are few books on the topic (I think an O'Rielly book on it was supposed to come out years ago on then got mysteriously pulled), and very few Java projects use it. It's a different mindset and a different set of goals between .NET and Java, and I think that Gosling is perfectly justified in pointing out the dangers of the path the Microsoft is taking.

Re:Inaccurate comparison (1)

Alt_Cognito (462081) | more than 9 years ago | (#11600033)

Correct me if I'm wrong, but doesn't the SWT use JNI - it certainly links to some native windows GUI DLL calls. That's used by Eclipse - eclipse is by no means a small insignificant project.

Inaccurate Inaccurate comparison (5, Informative)

steve_l (109732) | more than 9 years ago | (#11600105)

JNI is the second edition at a Java to C++ API. It is the underpinnings of every binding from Java to platform there is, not an afterthought for applets (though Netscape were involved). If you don't use it much in your code, it's because other people (i.e Sun) do it for you. They also go out their way to make it hard to do so, whereas MS, with P/Invoke and COM support, make it really easy to invoke native code *from trusted apps*.

Most .NET code that I know doesn't use unsafe either: MS go out their way to discourage you. You have to compile as unsafe, grab pointers only briefly, and then only ever get to run if your code came from a trusted place. All remote code is blocked, even that on a network share.

Where MS do care is about COM integration, about platform integration. True, there is only one platform they care about, Windows.

But consider this: Integration between Java and Linux, especially the GUI, sucks. Want decent Java/Gnome bindings? You need the third party Java-Gnome libs, which use, wait for it, JNI. Want Java KDE bindings, go to KDEJava and get the java libraries plus native code. If you want to integrate with the OS, you need native code, which means JNI.

The fact that JNI is pretty rare can be seen by the fact that Gnome, KDE and drag-drop integration with the rest of the Linux GUI is pretty much nonexistent.

I think the FUD Sun are saying about "unsafe" is so bogus. If they want to slag it off, just pick on the .NET APIs, too much of which are thin wrappers around Win32. OR the fact that the .NET runtime needs IE6 installed, and IE6 is the web browser component for .NET apps. OR the fact that ASP.net is built on IIS. Those are security holes. Windows is a security hole. ActiveX is a gaping security hole. IIS is server side disaster. .NET is actually pretty secure, but its just damage limitation on an otherwise dangerous piece of junk. Its like having ABS brakes on a Ford Explorer; not enough on its own to stop you crashing and burning horribly.

Re:Inaccurate comparison (1)

funk_doc (738861) | more than 9 years ago | (#11600145)

A point not made is that there is only one CLR, if there is an exploit for it, it will work in ANY .NET application. There are however dosens of implementations of the JVM. An exploit for one JVM wont necessarily work in another JVM.
This is a common theme for Java applications, an interface is published, and many compaines will implement it.

Re:Inaccurate comparison (1)

soulhuntre (52742) | more than 9 years ago | (#11600708)

"An exploit for one JVM wont necessarily work in another JVM"

Hell, in a lot of cases even non-buggy code for one JVM can't run ont he others. This is one of the places where Java fell down big time.

Why "managed" == "denial" (5, Insightful)

Concern (819622) | more than 9 years ago | (#11600006)

When .NET was first announced and the details began to be known, there were a number of lively discussions here about it. The "feature" of running unmanaged code was hotly debated, but the debate seemed to me to be entirely one-sided. It seemed clear unmanaged code is another classic Microsoft mistake - trading sugary convenience today for billions in headaches for their customers tomorrow. I went looking for someone to convince me otherwise and didn't succeed. Maybe now?

There is great value in a "managed" system like the Java VM. It gives us an extraordinary amount of safety that we are frankly unaccustomed to. People are still gradually learning how to think about it, but you see more and more security-critical projects going "Java only" as they figure it out.

There is also obviously no way we can do everything that way. For hot code, we work at lower levels, put in more work, and (for now) accept the additional risks. Note that the constant stream of ugly worldwide security problems is gradually but now noticeably decreasing our apetite for doing everything that way.

As far as I can tell, by allowing unmanaged code in the runtime, .NET gives you only the worst of both worlds.

You get all the overhead of the VM, but you don't really get safety.

I know perfectly well you can tell the .NET runtime not to allow unmanaged code. That doesn't matter, because the choice is there, "unmanaged" is still a huge problem.

Either it is avoided by everyone (everyone recognizes that it's a mistake), or we all begin to use it (it's in XYZ library), and then we all end up allowing unmanaged code, and we are no longer safe.

Why "managed" != "denial" (2, Interesting)

mark99 (459508) | more than 9 years ago | (#11600053)

I write a lot of C#, and I almost never use unmanaged code.

But sometimes I do. I would start far fewer projects with C# if I couldn't be sure I could get out of that particular straightjacket.

That being said, I am starting to have my doubts about writing huge programs without giving a thought to memory management. It is fun, and it is fast, but there is no way back...

Why no tainted data in either runtime? (2, Insightful)

steve_l (109732) | more than 9 years ago | (#11600130)

You make some good points. Nobody does use unmanaged BTW, its just too painful. There is one thing wore than it: managed C++.

One thing though, neither Java or .NET have any notion of tainted data. all this security stuff does is let you run untrusted code in a sandbox, or trusted code in a secured zone to slightly limit the damage it can do.

But neither language has the idea of marking strings or other data that came from an untrusted source, the way Perl does. Which is odd, as both Java and .NET have so far succeeded server side.

Compared to Perl, Java is insecure as you can too easily fall to a SQL string attack, either in your web page, or, heaven forbid, Web Service.

Re:Why no tainted data in either runtime? (2, Interesting)

pHDNgell (410691) | more than 9 years ago | (#11600332)

But neither language has the idea of marking strings or other data that came from an untrusted source, the way Perl does. Which is odd, as both Java and .NET have so far succeeded server side.

Why bother with tainting when you can just do rigorous validation with things like struts? It's been quite a while since I've seen a bug related to inappropriate input handling, and that was in a perl script.

Compared to Perl, Java is insecure as you can too easily fall to a SQL string attack, either in your web page, or, heaven forbid, Web Service.

It's actually rather hard to fall victim to a SQL injection attack unless you are just using the APIs the wrong way (which is more difficult). In our application...I can only think of a couple of places where SQL is generated in the code, and in those places, we generate prepared statements to deal with any input.

Re:Why "managed" == "denial" (3, Interesting)

graznar (537071) | more than 9 years ago | (#11600136)

There is great value in a "managed" system like the Java VM. It gives us an extraordinary amount of safety that we are frankly unaccustomed to.

Which I'm guessing your misinformation leads you to believe that .NET doesn't afford?


There is also obviously no way we can do everything that way. For hot code, we work at lower levels, put in more work, and (for now) accept the additional risks. Note that the constant stream of ugly worldwide security problems is gradually but now noticeably decreasing our apetite for doing everything that way.


Right...for "hot code" .NET developers use Interop to access lower level APIs and interfaces.


As far as I can tell, by allowing unmanaged code in the runtime, .NET gives you only the worst of both worlds.

I'm not really sure why you're wailing on .NET; security is a holistic effort. Your sysadmin needs to disable access to dangerous operations; the developer needs to put in place security measures (regardless of what language); the user needs to know how to operate software.

JNI does essentially the same thing as Interop. People who have been using JNI in its originally intended context don't see this, but some people use JNI to access lower level interfaces and APIs (such as shared memory, native APIs, etc.).

Now, of course, I'm sure you'll gloat about the proverbial "sandbox" that Java offers, but you fail to realize that .NET has this also. Try running an assembly off a remote store or even run a method through a remote channel. .NET's standard security is pretty high. It respects system permissions and principals, so I'm not sure why people keep saying it's some sort of apocolyptic risk.

Unmanaged isn't any different than writing a program and using JNI to talk to it.

Re:Why "managed" == "denial" (2, Insightful)

Concern (819622) | more than 9 years ago | (#11600700)

I'm sure you'll gloat about...

Relax.

Try running an assembly off a remote store or even run a method through a remote channel.

I'm aware that the default security configuration in .NET is not Pants Down for remote code.

I don't want to confuse "attack" with "mistake." What about problems in local unmanaged code that we wrote ourselves?

Unmanaged isn't any different than writing a program and using JNI to talk to it.

I don't know how good a comparison this is.

Any VM must use "managed" code to interface with lower-level "unmanaged" code. This is what you see in any core library: wrapper objects that invoke unmanaged native code. No PC is "managed" down to the silicon - although some Java embedded devices literally are.

The difference is in how that boundary works. In Java, JNI is deliberately very rudimentary and extremely low level. It is designed exclusively to allow access to native routines - not bit twiddling within the VM itself. It's use is vehemently discouraged by policy (100% pure etc etc) and JNI use in the field is rare as a result.

Everyone can hammer on the fixed Java API, and at some point we trust that lower-level foundation. We then declare that our own Java code, built on top of it, is "safe" and "managed."

In .NET, if I understand correctly, the attitude is very different.

http://msdn.microsoft.com/library/default.asp?ur l= /library/en-us/dnreal/html/realworld06012004.asp

They encourage the use of unmanaged code, and the framework makes it much, much easier to use. It's billed as a feature.

We slip in unmanaged C# to fiddle with buffers to do parsing or whatever. This is not going to C like in JNI, but just quick-and-dirty cheating within the VM. There is no such thing as "unmanaged Java."

So you can cheat the VM and make C# a little faster. But now no one is looking over your shoulder. Your new unmanaged code may have problems. You are not safe in your VM anymore (nor are you portable). Meanwhile you still have the overhead of running that way.

It often comes up in the Java community that people wish JNI did more work for you, so that it would be easier to use. But we always come back to the same answer: if you make JNI easy, and start encouraging its use (going the Microsoft route), soon everyone is using it. There is no more portability and you lose security and stability. Great for MS, of course. But if we really don't care about that, why not just back away from the VM in a more orderly fashion altogether?

Welcome To Microsoft's Security 'Solution' (0)

Anonymous Coward | more than 9 years ago | (#11600039)

"I know you are but what am I!"

Nya,nya,nya...

Whiny (4, Funny)

5n3ak3rp1mp (305814) | more than 9 years ago | (#11600155)

I can't help feeling that some small percentage of this type of back-and-forth is something like a junior-high whiny geek arguing about how the Micro Channel bus architecture is better than ISA and that , incidentally, Apples are utterly irrelevant. ...Oh, wait. That geek was at one time a friend of mine, and this was circa 1985, and this was an actual discussion. ;) (hi, don ulrich! i still use a Mac, and Apple still exists! where's your precious PS/2 micro-channel NOW?!?! nyaaah, nyaaah!!)

What Mac bus in 1985? (1)

swb (14022) | more than 9 years ago | (#11600389)

Did any Mac in 1985 even have an expansion bus?

I'm not including the XL because it was a Lisa not a Mac, and the Lisa expansion slots were more useless then than ISA is today.

I'll agree with your main point, though.

Re:Whiny (1)

man_ls (248470) | more than 9 years ago | (#11600460)

Being superior in terms of technical specifications, and market forces, are very different.

Microchannel Architecture was a 32-bit bus far ahead of its time, it was very fast, but IBM kept the specs so tightly controlled that MCA devices were expensive as hell, and as a result, not widely produced.

Just further proof... (0, Troll)

CptSkippy (793400) | more than 9 years ago | (#11600220)

Just further proof that when Microsoft sat down to write .NET they took their JVM (that Sun defeated in the courts) and did some keyword replacements on the source and came up with C#.

Neither is really a security hole.... (5, Interesting)

Jaime2 (824950) | more than 9 years ago | (#11600301)

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.

I don't see the big fuss (2, Insightful)

Rocko Bonaparte (562051) | more than 9 years ago | (#11600302)

Some people just have to do low-level stuff in a high-level application. People can write malicious code for that, but that's the price you pay.

The little bit of C# I've looked at has shown that .NET does a lot to reduce the amount of old-fashioned pointers you need. Most of that has been wrapped up into things like references and delegates, which can be tracked and managed.

They could have also prevented C++ from coexisting with the .NET framework, but I think that would have reduced a huge selling point. .NET is more than just a VM, and it's trying to solve a lot of problems. C++ should be able to take advantage of it.

I think people are just complaining is on the assumption that .NET will become the next overwhelming thing, and it's VM will be widely adopted--hence the biggest target for attacks. It's very possible to write a JNI exploit that the naive user may also run. Ultimately, accountability still resides with the end user, but these higher-level languages have reduced the amount of stuff the end user has to track.

I can already see it (0, Offtopic)

Hyksos (595814) | more than 9 years ago | (#11600380)

Quite a cool surname... Box. I bet that most slashdotters would call his family the Boxen :P

Ah, yes... SOAP... (2, Interesting)

Anonymous Coward | more than 9 years ago | (#11600462)

"See, it's XML over HTTP, so no need to change your firewall configuration". Security? Ah!

And Microsoft bought into it because they needed something to interoperate with the rest of the world, and they couldn't do a 180 and use CORBA without "looking bad".

And now we get that XOP turd (discussed here [slashdot.org] [slashdot.org]), because somebody wisened up and realized that XML was just bad at byte framing, and, yes, we need binary data.

From the 'Yeah, well, duh!" department (2, Interesting)

scovetta (632629) | more than 9 years ago | (#11600493)

JNI is an absolutely necessary part of Java. How do you think System.out.println() really works? Down through the (many) layers of calls within standard Java classes, you eventually get to a JNI call. In fact, without JNI, Java wouldn't be able to access the network, files, console, etc. It's like saying the keyboard is responsible when you type format c: (or when you click-click-click for the younger generation).

C++ support in Java vs .NET (4, Interesting)

DrXym (126579) | more than 9 years ago | (#11600643)

Yes Java supports C++ native calls, but look at how bloody painful it is to do it. You have to define an interface, run it through a stub compiler, implement the stubs and use helpers to marshal types back and forth between C++ and their Java equivalents. It involves lots of files and lots of fiddling about.

The consequence of this is that no-one uses JNI unless they absolutely positively have to. It's a pain and life is much easier if everything is in Java. Thus with the exception of a few esoteric things such as SWT, most libraries are pure and portable.

Now contrast this with .NET. Writing native C++ and wrapping it in a garbage collection safe class involves no stub generation and can be done in a single file - the assembly info, interface and gc wrapper can all be specified in situ. Consequently it's a lot easier to pull C++ into a .NET application. MS DevStudio 2003 even has wizards to do it. It is also a lot easier to call DLLs and ActiveX from .NET since MS provide PInvoke and COM Interop to do just that.

Now on the face of it, this is all well and good, especially if you have a lot of legacy crap to port. But by the same token it means many more .NET apps are tainted than on Java. The problems this causes for portability should be obvious.

And this is called "Microsoft having their cake and eating it". They can expound portability and present the facade that .NET is cross-platform, when in reality they provide tools and wizards to ensure it remains anything but. Apps that are infested with native instructions and OS-specific calls are by definition unportable.

Mono demonstrates the problems faced in porting .NET to other platforms. Mono must literally pull in the whole winelib in order to cope with the number of tainted .NET apps that attempt to call out to Win32. And too bad if you're running Mono on a non-x86, non-Linux system since winelib is x86 only (for now).

And I don't see the situation getting any better. Perhaps if Mono gains momentum it might put the brakes on tainted code, but there is a long way for that to happen. I believe the only way Mono is going to make an impact is if ships with a cross-platform IDE with tools that default to its open source stack. This is almost a reality since ICSharpDevelop & MonoDevelop are both fairly complete IDEs but there is nothing yet which defaults to the open source stack and runs on all major platforms.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...