Slashdot Mirror
Don Box: Huge Security Holes in Solaris, JVM
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."
First instance of Microsoft mehing FUD?
Next up, Notepad will be the target since it allows any malicious code to be written on it.
Rock that crushes, Paper & Scissors that don't matter.
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
I can see it now..."Bugs deserve rights too!"
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.
Bill_Gates.m4a Warning, it is on a slow connection.
MS calls it "Indigo"...
Do I smell a lawsuit from SGI?
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.
Is this the new Microsoft Box model?
Since Java and .NET are both so insecure; by subtraction, F/OSS is the most secure stuff around!
is this one of those, "your hole is bigger than mine" arguments?
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
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
Going back to SGI, eh? Iris Indigo
A feeling of having made the same mistake before: Deja Foobar
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.
Just a boy doing unproffesional IT work that's way above his head.
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
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!
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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!
.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.
So the only really safe language to be using, in truth, is HQ9+. Rather than leaving the opportunity for error as Perl, Python, Java and
Size doesn't matter, It's how you use it.
(sorry)
Intercal! It's very hard to write viruses using it.
(It's very hard to write anything else in it either)
Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.
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.
Cat, the other, tastier white meat.
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.
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?
.NET gives you only the worst of both worlds.
.NET runtime not to allow unmanaged code. That doesn't matter, because the choice is there, "unmanaged" is still a huge problem.
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,
You get all the overhead of the VM, but you don't really get safety.
I know perfectly well you can tell the
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!
"I know you are but what am I!"
Nya,nya,nya...
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...
I'll don huge security holes in your box!!!
I like suggestions, but I don't like contributing towards them.
So when will this become a serial exchange of yo momma jokes?
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*.
.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.
.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.
Most
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
You make some good points. Nobody does use unmanaged BTW, its just too painful. There is one thing wore than it: managed C++.
.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.
.NET have so far succeeded server side.
One thing though, neither Java or
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
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.
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!!)
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.
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#.
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.
.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.
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
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.
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.
.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.
.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.
.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.
The little bit of C# I've looked at has shown that
They could have also prevented C++ from coexisting with the
I think people are just complaining is on the assumption that
No I'm not trolling.
Quite a cool surname... Box. I bet that most slashdotters would call his family the Boxen :P
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.
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.
"Get out of your web services, connect to database world."
.NET. Only somebody with an agenda thinks otherwise.
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
"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]), because somebody wisened up and realized that XML was just bad at byte framing, and, yes, we need binary data.
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).
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
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.
sigs are a waste of space
Realtime and embedded systems are actually one of the big growth areas for Java right now. The research work in Java is already getting closer and closer to the hardware... we'll just have to see how far that goes.
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.
http://shit.slashdot.org/article.pl?sid=05/02/07/1 835232
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
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
http://www.cultdeadcow.com/cDc_pix/CDC003.JPG
http://www.messyfun.com
As far as I remember, JNI simply wraps a C/C++ component's function exports into a standard API whilst security permissions are implemented at component load/runtime.
If configured correctly, .NET's security model is seems superior. Allowing you to supply policies of trust to your own wrapped code and whilst excluding anyone elses. Of course, as with all things, if you really really want to misconfigure something you *could* use this to really *uck up your employer's systems.
Disclosure - C# & C++/CLI developer
- This and all my posts are public domain. I am a Physicist. I am not your Physicist. This is not Physically advice
But the starting point for the flamewar was Gosling doing precisely that.
I get really tired of security being thrown around to score idiotic debating points. That is what Gosling was doing, if he had bothered to do any research on the .NET security framework he would know that the security mechanisms prevent the type of mixing he was complaining about.
Don's description of the problem is completely straightforward. There are three possible cases and everyone agrees that Java supports two of those cases. C# adds another case because the designers did not want to have to abandon code management just to avoid the type system.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Goesling's comments made me laugh. .NET can run unmanaged C/C++ code, therefore is unsecure. Well, Java can do the same thing, with JNI (and JNI is necessary in some cases.. anyone know how to read the MAC address of your NIC without it, for example?)
.NET is as secure as Java wrt unmanaged code .NET is more convenient wrt the same
Essentially, Don's comments are:
a)
b)
which is completely correct, IMO.
I am the maverick of Slashdot
if he had bothered to do any research on the .NET security framework he would know that the security mechanisms prevent the type of mixing he was complaining about.
Unless your browser is tricked into saving to the local zone, where you can run 'assemblies' that use 'unmanaged' code (ie, ie). Seriously though why did they take good Java names terms like 'safe code' or 'pure java' and rename them as corporate dronespeak like 'managed code'. Yuk.
It's funny how, across the aisle, the celebrity hackers in this tale are simultaneously poking fun at the willfully non-technical folks who pay them and the accidentally non-technical folks who worship them in forums like /..
Lucky them. At least they have tenure.
Don Box sucks cocks!
A typesafe language is no replacement for secure programming knowledge, several vendors offer classes in that realm:
n g_Training.htm
http://www.liveammo.com/LiveAmmo_Secure_Programmi
and
http://www.cerias.purdue.edu/secprog
---------- http://www.LiveAmmo.com
Bah, Intercal is easy to write. Reading and maintaining it is another matter, but you can write it no problem. Try Malbooge (sp?) for something hard to write.
I am trolling
I don't think I missed the point at all. JNI and unmanaged code are not the same, and I think comparing them is deceptive.
I went into some detail about this here.
Tired of Political Trolls? Opt Out!
In JNI, to access Java objects, you must do so via JNI function calls. That way, to invoke a Java method, the JVM can verify that the jobject handle you supply is of the correct class and that the method does exist and is valid for that object, therefore maintaining the integrity of all JAVA objects.
Gosling's point is that in C++, you are able to manipulate .NET objects using C++ classes, and therefore you can easily corrupt them. You can do arbitrary casting in C++. The example he used was an Image. In C++, you could theoretically cast an Image pointer to a String pointer, and start invoking String methods on it and the .NET runtime will attempt to run them, corrupting the data.
Basically it comes down to this: even the JNI maintains type safety. But in .NET, it is possible to get around it. So his arugment is that Java is therefore a much more secure platform. Ofcourse you could call malicious native code from Java, but any data in Java objects will be safe.
That being said, I still think .NET is a wonderful platform. It just has its flaws. As does Java. BUt Gosling is just pointing out that their decision to support legacy C++ may have affected the overall design of the platform to allow unsafe operations, just because it is allowed in C++.
Gosling: ".NET has huge security holes"
Box: "well, duh, guess where we copied them from! Now go fix the JVM so we copy your improvements and fix our CLR."
Go hug some trees.
Sheesh I wish I had mod points. :(
Gosling wasn't starting a flamewar. If someones sane ideas on forgetting that unsafe checking ever existed, to try and stop 98.9923% of all problems in the IT world (*cough* those worms that take down the internet in 5 hours).
Do a seach for uncheck buffer, buffer overflow, and sanity check on your average security alert site.
The simple check that stops you going from place to place in memory is available to all. If it is so slow in Microsofts impl, and they have to disable it not necessarily to do unsafe ops, but to optimize xml parsing libraries, then they have a problem.
How do you feel installing something on your new server that has the keyword unsafe on 19 methods running on open ports on your server?
Of course, making sure that they are safe just takes more time and diligence on the part of the programmer. But building in a few security risks always keeps the customer asking for newer versions.
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
How do you feel installing something on your new server that has the keyword unsafe on 19 methods running on open ports on your server?
.NET security model and the Java one for that matter, as he either has no idea of how they work or he's deliberately trying to mislead.
And this is the truth of the matter. People not familiar with C#/.NET see the word unsafe and assume it means the code is doing something bad. It doesn't. Microsoft could've chosen any keyword for this, but they chose such an emotive term because it forces programmers to consider whether they really want to do it that way - after all would you like to call your code unsafe?
As Don pointed out, the use of "unsafe" is predominantly for dealing with things like interfacing with the SSPI interfaces for native Windows security. To achieve the same thing with Java would involve JNI.
Gosling really needs to go and read up on the
I reviewed two 'how to use Java Web Servies' papers last year that were due for online publication, both were vulnerable to SQL attacks.
now, this wasnt production code, but if people showing developers how to write a fancy SOAP endpoint to existing code dont mention that there is no validation of data, do you think readers will remember to do it?