Don Box: Huge Security Holes in Solaris, JVM

JNI is an API, not a platform... by patniemeyer · 2005-02-07 07:46 · Score: 4, Informative

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... by Rinikusu · 2005-02-07 07:51 · Score: 3, Informative

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?)

--
If you were me, you'd be good lookin'. - six string samurai
Re:JNI is an API, not a platform... by essiescreet · 2005-02-07 07:55 · Score: 3, Informative

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... by Anonymous Coward · 2005-02-07 07:56 · Score: 3, Interesting

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... by patniemeyer · 2005-02-07 08:03 · Score: 4, Informative

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... by squiggleslash · 2005-02-07 08:15 · Score: 4, Interesting

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.

--
You are not alone. This is not normal. None of this is normal.
Re:JNI is an API, not a platform... by patniemeyer · 2005-02-07 08:25 · Score: 3, Insightful

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... by jeif1k · 2005-02-07 08:32 · Score: 4, Insightful

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... by jeif1k · 2005-02-07 10:13 · Score: 3, Insightful

which high level languages were these, and is the greater safety not in large part due to the relative simplicity of older systems

Many of the classics, among them Lisp, Algol, APL, Simula, and Smalltalk. Modula-3 even had C#-like safe/unsafe sublanguages (as did a few other languages). And while they didn't have GC, languages like Pascal and Modula were safe languages in most other respects.

and is the greater safety not in large part due to the relative simplicity of older systems? I mean, how hard is it to wring all the bugs out of an application or OS written for a machine with 16K of RAM

The world did not begin with 16k Apple II's or the teenage dabblings of some industry luminaries in software. People had large computers running multiuser operating systems and safe, high-level languages in the 1960's.

and did they really bother to weed out all possible "exploits" when weren't 10,000 russian teenagers writing viruses to "zombie box" that machine?

We are talking about runtime safety here. You are confusing runtime safety and security; runtime safety helps with security, but it is neither necessary nor sufficient to guarantee it.

I don't think anyone really read what Gosling said by Anonymous Coward · 2005-02-07 07:52 · 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.

Re:Flaws aren't a bad thing? by Rosco+P.+Coltrane · 2005-02-07 07:53 · Score: 5, Funny

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

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

--
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash

here we go again.... by kevinx · 2005-02-07 07:53 · Score: 5, Funny

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

FUD by micromuncher · 2005-02-07 07:55 · Score: 5, Informative

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.

--
/\/\icro/\/\uncher

This just in! by kiwidefunkt · 2005-02-07 07:59 · Score: 5, Funny

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.

--
www.kiwilyrics.com - a wiki for lyrics

Why "managed" == "denial" by Concern · 2005-02-07 08:15 · Score: 5, Insightful

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.

--
Tired of Political Trolls? Opt Out!

Re:Why "managed" == "denial" by graznar · 2005-02-07 08:29 · Score: 3, Interesting

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.

--
[ check out my ruby book @ http://ww

Hmm.. by vurg · 2005-02-07 08:21 · Score: 5, Funny

So when will this become a serial exchange of yo momma jokes?

Re:What do these both have incommon? by javatips · 2005-02-07 08:24 · Score: 4, Informative

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

Inaccurate Inaccurate comparison by steve_l · 2005-02-07 08:25 · Score: 5, Informative

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.

Whiny by 5n3ak3rp1mp · 2005-02-07 08:31 · Score: 4, Funny

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!!)

Neither is really a security hole.... by Jaime2 · 2005-02-07 08:46 · 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.

C++ support in Java vs .NET by DrXym · 2005-02-07 09:21 · Score: 4, Interesting

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.

Heh by finkployd · 2005-02-07 09:49 · Score: 3, Funny

One of the creators of SOAP is lecturing on security, that is quite a laugh. SOAP still stands as the poster child for the "design something first, try to hack on security after the fact" crowd.

Finkployd

Slashdot Mirror

Don Box: Huge Security Holes in Solaris, JVM

23 of 226 comments (clear)