login      my ps      about      contact  



home instructor-led on-demand! screencasts blogs technical staff


Don Box's Spoutlet » Huge Security Hole in Solaris and JVM

Huge Security Hole in Solaris and JVM

Don Box's Spoutlet

Pluralsight Blogs

Syndication

Recent Posts

Tags

View more

Oslo

Archives

I wonder how Gosling feels about Solaris and the JVM, both of which support execution of C and C++ code (the latter through JNI, the former as the default way lots of UNIX heads (including me) learned to write UNIX code).
 
Seriously, verifiable type safety is a wonderful thing, and I personally strive to stay within those borders every day of my life. 
 
The fact that some people can't is a fact of life, which is why JNI (and the CLR's P/Invoke and C#'s unsafe) exists. 
 
Ignoring the hyperbole (which is sad but a reality of the commercial software business), there was one annoying bit of misinformation about unsafe vs. unmanaged.
 
In CLR speak, there are two modes of execution: managed and unmanaged.  Some managed code is verifiably type safe, some is not. Got it? That's three kinds of code:
 
  1. Verifiable and Managed.  This is what the C# compiler emits by default, and it’s the only thing the VB.NET compiler can emit.
  2. Non-verifiable and Managed. The C# compiler can be told to emit this sort of code by passing the /unsafe keyword. The only reason to do this is if you are using the unsafe keyword in C#.
  3. Non-verifiable and Unmanaged.  The CLR makes no attempt to verify type safety on unmanaged code. This code is pretty much opaque to the CLR. 
 
The JVM supports 1 and 3.  JVC produces #1. JNI allows you to load #3.
 
The CLR supports all three.
 
You might ask, what good is #2? That's easy.
 
In systems programming, it's occasionally necessary to do low-level buffer manipulation, especially in I/O code.
 
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.  Every single use was to do buffer manipulation, either for low-level XML cracking, SSPI munging, or async I/O buffer management.
 
Could we have written those pieces in unmanaged C or C++?
 
Sure.
 
However, by using "Non-verifiable and Managed" C#, we got two advantages.
 
First, the code was written in the same language the rest of the DLL was written in, meaning that it's less of a cognitive mode switch for a dev to deal with when they go spelunking (or debugging).
 
Secondly, there is no "transition" for the runtime to go through when executing the code.  Both the CLR and the JVM have non-trivial runtime costs when transitioning from managed to unmanaged mode.  In contrast, unsafe vs. safe is not a runtime mode, rather its just an attribute of an assembly that tells the loader whether or not verification is expected to succeed.  In short, this means that yes, its faster.
 
I'd be remise if I didn't mention that code access security can disallow loading non-verifiable managed code, and the default is that it cannot be loaded from remote stores.  You can use caspol.exe to tighten this down further.
Posted Feb 06 2005, 01:56 AM by don-box

Comments

Sahil Malik wrote re: Huge Security Hole in Solaris and JVM
on 02-05-2005 9:56 PM
cnet/zdnet is one of the most anti microsoft bigot sites you can come up with. It's ridiculous why such sites exist and even have a fan following.
MC wrote re: Huge Security Hole in Solaris and JVM
on 02-06-2005 4:31 AM
Thanks Don,..you really gave the answers..BTW why don't you publish this as an open answer to Gosling? Gosling has been telling this for sometime(I heard the samething when last year he visited the company in which I was working as a consultant)

-MC
Martin's WebLog wrote .NET is safe
on 02-06-2005 2:02 PM
Dave Donaldson's Blog wrote Indigo Written in C#
on 02-06-2005 7:22 PM
Kenneth wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 5:36 AM
The most frustrated thing in programming life and deployment in JAVA is memory leakage. Even JVM claim to be superior in GC and better memory model i think all this is just bullshit . I reading a system whom claim to be stable is the lowest level programming model where mistake cant be made. Look at RPG and TPF they are rock stable for the financial and airline industry. Weblogic , Sun One and Websphere all faces OutOfMemory Exception due to lacking of profiling in code.

I wouldn't say Microsoft approach is bad and leave security hole open but no perfect language at this moment !
Anonymous Coward wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 5:58 AM
> I'd be remise if I didn't mention
> that code access security can
> disallow loading non-verifiable
> managed code, and the default is that
> it cannot be loaded from remote
> stores.

Does that mean you can sign unmanaged C/C++ code like a signed applet? What does "non-verifiable" mean?
Dr. Confused wrote Allegations over CLR and C#
on 02-07-2005 6:17 AM
I am no microsoft fan, but stating a feature in CLR and C# is insecure based on pure speculation is just dumb.

I am starting to lose credibility over certain individuals in the java land :-)

Anyway, great reply Don.
Jakob Praher wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 6:45 AM
some further investigation - I think that Mr. Gosling is right to some degree. CLR is simply not the most secure execution envronment.

please drop me a mail if you don't think so: jpraher@yahoo.de
Don Box wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 7:05 AM
Jakob,

In looking at your page, I think you’re missing the point wrt how the verifiability works.

Try removing the UnverifiableCodeAttribute attribute and reassembling the file with ILASM.exe.

You won’t be able to load it. We do verification too.

DB
Sushant Bhatia wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 7:10 AM
Jakob says "Note: My investigation is based on the mono compiler mcs, the mono vm, the mono disassambler monodis and the mono assembler ilasm" on his link. Is this a valid comparison?
Jakob Praher wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 7:16 AM
Hi Don,

thanks for your comments.
sure you can do verification, but it is much harder, and the discussion is about the likelyhood of security holes. if something is hard to track its easy to miss something that was my point in the discussion.

do you do verification on local exe/dlls too? probably mono doesn't do this right now (I'm using 1.05)
this means you walk throuhg the bytecodes and see whether there is some "unsafe" bytecode and then chek whether the attribute is set, right?

-- Jakob
Steve Loughran wrote JNI invocation costs
on 02-07-2005 7:46 AM
I've just been rerunning some JNI round-trip time experiments. The #of cycles to go to JNI and back has gone up from 150 cycles on PII to 320 on P4 Xeon, which is atrocious. Either JNI is particularly slow on P4, or Java JIT compilation and P4 don't get on.

Interestingly, the time on Pentium M has dropped down to 124 cycles; it has improved over PII.

Has anyone done the experiments on CLR/native invocation to see whether it is as bad?
Don Box wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 7:52 AM
Jakob,

If you try to load the executable from a codebase that has full trust (like your local hard drive), then it shouldload.

If you try to load the executable from a codebase that doesn't has full trust (like an UNC path to a remote share or over HTTP), then it should not load.

I can't speak for Mono, but this is what the CLR just did on two of my boxes.

DB
Michele Leroux Bustamante wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 7:56 AM
Don,

Isn't it also true that since the JIT compiler compiles per method, that only the method with unsafe code is marked non-verifiable? Meaning, the entire assembly does not skip verification?

-Michele
Joe Stagner - Frustrated by Design ! wrote UPDATE-DORK AWARD: Java creator James Gosling (via Don Box)
on 02-07-2005 8:22 AM
Joe Stagner - Frustrated by Design ! wrote UPDATE-DORK AWARD: Java creator James Gosling (via Don Box)
on 02-07-2005 9:45 AM
Joe Stagner - Frustrated by Design ! wrote UPDATE-DORK AWARD: Java creator James Gosling (via Don Box)
on 02-07-2005 9:45 AM
Klaus H. Probst wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 11:13 AM
Get ready Don, someone just submitted this to Bashdork.
Judah Himango wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 11:15 AM
Oh boy, here come the slashbot dorks, whining about MS and praising Linux blindly. Brace yourselves...
Heath Stewart wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 11:27 AM
A story is already running on Shashdot at http://it.slashdot.org/article.pl?sid=05/02/07/1835232&tid=172&tid=108&tid=8 and already everyone on the "M$ bandwagon" who know nothing of the CLR and CAS, nor the JVM and its sandbox, is poking fun with the usual rhetoric (BS).

You get right to the heart of the matter, Don. People need to understand that P/Invoke and COM interop (or even "C++ interop, as the Whidbey guys are calling it) allows the CLR to be flexible and it is kept in check through CAS, which is far more stringent than Java's sandboxing (though my experience dates back several years with that).

People, if unverifiable code is not allowed to execute by the code group that controls the assembly based on its evidence, then unverifiable code will not run or even load (SecurityPermissionAttribute.SkipVerification). The same goes for unmanaged calls using a separate security permission (SecurityPermissionAttribute.UnmanagedCode).

The default permission sets are fairly good and they can be made tighter if administrators or individual users require it. As Don said, any code from remote stores by default cannot load unverifiable code. It also can't make unmanaged calls.
Kannan Goundan wrote James Gosling: FUD machine
on 02-07-2005 11:53 AM
I used to think Gosling was a pretty smart guy. This article makes him look like a Sun PR puppet. It's really sad that the "journalists" even printed that garbage.

Unsafe code is really a great idea. Sure, it's great that it's faster to switch in and out, but my favorite thing is that it's portable! JNI requires that a C compiler be run for every possible deployment target. With unsafe code, the VM takes care of everything transparently.
John wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 12:00 PM
As you well know, what Jim was saying is that the CLR allows the execution of insecure bytecode. That is something the JVM will not. No matter how you try to deflect attention from it, you can't. It is a gaping security hole, unique to .NET, and impossible in Java. The Java bytecode verifier runs every time, and will not load unsafe code, under any circumstances.

However, Jim said it was the "biggest and most offensive mistake that they could have made"; there I think he is wrong. Microsoft has made much bigger and much more offensive mistakes in the past, and will easily surpass this one in the very near future.
Robert wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 12:01 PM
For a good background article on how the designers of Java think, feel, and act, take a look at this article about Patrick Naughton. http://www.rotten.com/library/bio/crime/criminals/patrick-naughton/

After reading that, I never touched Java again.
julian_t wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 12:10 PM
John said... "As you well know, what Jim was saying is that the CLR allows the execution of insecure bytecode. That is something the JVM will not. No matter how you try to deflect attention from it, you can't. It is a gaping security hole, unique to .NET, and impossible in Java. The Java bytecode verifier runs every time, and will not load unsafe code, under any circumstances."

OK, so what's the *practical* difference between unsafe bytecode executed from C#, and C code being executed via JNI from a Java app? In the JNI case, the JVM just has to cross its fingers and hope the external (unsafe!) code doesn't do anything bad. Another Gaping Security Hole (tm), really....


Kannan Goundan wrote James Gosling: Hypocrite too!
on 02-07-2005 12:20 PM
Gosling says (from the article): "So if somebody gives you an object and says 'This is an image', then it is an image. It's not like a pointer to a stream, where it just casts an image."

It's ironic that when Generics are involved, the JVM doesn't preserve this guarantee. A List<String> might contain a couple of AbstractQueuedSynchronizers. Though the new Java compiler will be strict about what it lets you put in, you can craft "bad" bytecode that the JVM will happily verify (in fact, just use an older version of 'javac' to produce that bytecode).

Any code that uses generic type instances from an untrusted source has to be aware that ClassCastExceptions can pop up even though there are no casts in the source code. This loophole just makes life harder for the security-conscious programmer.

--

public class Printer {
static void printAll(List<String> l) {
for (String s : l)
System.out.println(s);
}
}

> javac Printer.java

public class BadGuy {
public static void main(String[] args) {
List l = new LinkedList();
l.add("Hello");
l.add(new Integer());

Printer.printAll(l);
}
}

> javac -source 1.4 -target 1.4 BadGuy.java

> java BadGuy
Hello
Exception in thread "main" ...
Jakob Praher wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 12:23 PM
I've updated my documentation to reflect the response I've gotten from you.

I don't want to say that unsafe code is bad idea with every respect - the argument that it's portable code and you don't have to compile it is clearly an advantage - but it does impose much more burden on the verifer that's for sure.

and I wanted to say that though the comment from Mr Gosling is bit too broad, after all that worms and stuff like that, you know how clever crackers are :-) And I've got to say that the CLR execution environment is very close to the usual C model - which is really powerful, but also dangerous ...
John wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 12:24 PM
Don is saying that there are two very easy ways to compromise the integrity of your box with CLR, and only one, admittedly suspect method, with JVM. Perhaps in Microsoft mentality this is somehow construed as a feature.

The real question is julian; given these circumstances, why not just compile all your code? It is already non-portable to other platforms.
Kannan Goundan wrote How is this still unclear?
on 02-07-2005 1:46 PM
John & Jakob (& Jingleheimer & Schmidt!):

The security properties are the same!

1. Trusted code can do whatever it wants:

Local JVM bytecode code *can* use JNI. JNI can do unsafe things. The JVM will not stop this.

Local CLR bytecode *can* use either managed or unmanaged unsafe code. The CLR VM will not stop this.

2. Untrusted code must be verified:

Untrusted JVM bytecode is NOT allowed to use JNI.

Untrusted CLR bytecode is NOT allowed to use either managed or unmanaged unsafe code.

By default, remotely loaded code is not trusted in either system. You can change this if you want.

--

John:

You say the CLR has "two very easy ways to compromise the integrity of your box". I assume you're referring to managed/unsafe and unmanaged code. You also say that the JVM has "only one, admittedly suspect method". I assume you're referring to JNI.

First of all, CLR unmanaged code and JNI are basically the same thing! Both VMs will not allow untrusted code to use those execution methods. The fact that you consider one to be "very easy" and the other to be "admittedly suspect" implies extreme bias on your part.


Secondly, the CLR treats managed/unsafe code with the same distrust that the JVM treats JNI code. The only difference is that managed/unsafe code is faster to call and more portable (because it doesn't use native instructions until JIT). That is why it is definitely a feature.

"Why not compile all your code?" Why do you ask this only of the CLR? The JVM with JNI is the same thing!
Matt wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 1:55 PM
This article is titled "Huge Security Hole in Solaris and JVM". However I have just read through it and cannot determine what this security hole is in Solaris you talk about.

Can you please explain?
Bertrand Le Roy wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 1:57 PM
Jakob, your tests should be made with .NET, not with Mono. As you can easily check from the Mono roadmap, "A missing component of Mono is the Code Access Security (CAS). This functionality is not needed in today's Mono as currently Mono is being used to run fully trusted applications, and we are not using it on embedded scenarios where assemblies would have different trust levels."
Derek Chen-Becker wrote Forest for the trees?
on 02-07-2005 2:17 PM
Just to clarify, it sounds like you can only remotely load type 1 (safe, managed code) in C#, just like Java does in a browser JVM or via RMI. If that's truly the case then I don't think Gosling's argument holds that much merit. If he's saying you can download an executable and run it then that's not saying much, because you can write a trojan in any language (even Java).

I think it's an interesting academic exercise to figure out the exact differences in verification, but I think that broader problems with secure programming are much more fundamental than this; like transmitting passwords in the clear, not verifying user input, or using unquoted SQL strings with user input.

One last note: just because there are a few idiots on Slashdot doesn't mean we all are, nor does it mean you need to stoop to their level.
John wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 2:19 PM
Kannan,

"Why not compile all your code?"

What I mean by that is, once you give up on trusted code, the CLR buys you nothing, except overhead. Already it's not portable to anything but windows platforms, by design. (Don't get me started about mono, it's .NOT)

You'd be surprised at how rarely JNI is used, and the justly-deserved suspicion it raises. Using JNI has been labelled needlessly difficult, and I believe this is in fact intentional, just to discourage its use. In contrast, .NET makes using COM and native DLLs so easy, many people already do it regularly. Once people have to routinely trust .NET applications, interest in the platform will justifiably evaporate, as the platform brings no benefits over compiled code.
gipak wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 2:20 PM
Question: What kind of operation that is absolutely required in software design right now, if programmed in java, would require you to use JNI, and not "platform local" (like attempt to run "Mine Sweeper")? Are there many examples? Seriously asking.

I had only 2 such problems, one was accelerated 3D - solved by a library, no typing of c/C++ only adding one jar and two dlls, the other one was... hardware driver.

What would requrire you in java to write JNI? Not mocking, simply asking.

... Sorry but I the "javac -source 1.4 -target 1.4 BadGuy.java" thing is pathetic, it results in an exception, the real problem would appear if the cast was succesful, does .NET do type checking in C/C++ im affraid thats what gosling meant. Correct me if im wrong.

gipak wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 2:27 PM
if c++ code is portable it probably can be replaced with c# so where is the need for it?
Paul wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 3:25 PM
<i>Already it's not portable to anything but windows platforms, by design. (Don't get me started about mono, it's .NOT)</i>

mono works quite nicely for the things I'm doing with it. Produces code that works quite nicely under Windows, as well.

As for what does it buy you - well, apart from the fact C# is actually a fairly reasonable language in most ways, you get the .Net class library, which is extremely useful.

(I still think Python is even nicer to code for, but sometimes you just have to decide it's probably harder to link in everything else needed than to learn another environment ;)
James wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 3:33 PM
The BadGuy.java example is absurd because it uses a non-generics-capable compiler to drive generics-compiled code. The scenarios where this would happen in practice are pretty much non-existent.

The argument that Patrick Naughton is criminal and therefore you shouldn't use Java is even more absurd.

The fact that it is common to use native DLLs in C# code means that you can either use libraries that exist but are untrusted or ... what? Not run the program? Java had the flipside of this problem initially, many kinds of apps simply couldn't be written. With C# the app can be written, but not using trusted code.

As an educated consumer of software programs, of course I can decide not to run all sorts of programs that aren't trustworthy. I don't run Internet Explorer for just this reason.
Nick's Blog wrote Huge Security Hole in Solaris and JVM
on 02-07-2005 4:03 PM
Charles Moore wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 4:32 PM
Buffer overflows will not be our downfall, but I'll tell you what will: A generation of programmers who write code for virtual machines instead of real machines. If you C#/Java clowns have your way, that's what we're looking at. Back to your XBoxes, gamers.
Kannan Goundan wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 5:06 PM
James:

The BadGuy.java was an example of how a malicious person (the one who wrote BadGuy.java) can cause unexpected exceptions in your code (Printer.java). From a software design perspective, I agree that this situation isn't a problem because the "javac" compiler will warn you about this. However, I believe that we're talking about security here and from that perspective, *any* code that accepts generic type instances from untrusted code needs to be extra careful.

--

John:

"Why not compile all your code?"

First of all, it's really unfair to give Java a get-out-of-jail card on this one. You seemed to be doing that based solely on the fact that JNI is a pain in the ass. If pure Java lets you do things that aren't possible in verifiable CLR, then you have a reason to be concerned. This is not the case.

Java and C#/CLR both allow for unsafe code. C#/CLR's technique is easier for the developer, more efficient, and more portable. You consider this a problem? Take a Java applet, for example. Writing to the "My Documents" folder is an unsafe operation. It is also *really* easy to do in Java. The applet container won't allow this (just like a CLR applet container wouldn't allow the execution of unsafe code). Does this make java.io.FileOutputStream a security hole? Could the security of the Java platform can be enhanced by giving that class a tediously long name or by requiring that all hard drive file access be written in Cobol?

As far as locally installed code goes, I agree that safety doesn't matter as much. Locally installed CLR programs have access to your entire computer. If a program decides to wipe my hard drive, I really don't care about it's type safety properties. The same exact thing applies to JVM bytecode.

Verifiability is important for untrusted code. For example, if a web server process runs as "Admin", you need to make sure user-loaded modules don't compromise security. Safe execution environments are helping make this possible. Currently, we use the OS process barriers to achieve this, which is inefficient. A more efficient X-Windows server might allow you to upload an application's event-handling code to reduce the number of network round-trips.

Even if you don't care about verifiable code, JIT-ing still gives you some solid advantages over ahead-of-time compilation: cleaner linking (no vtable versioning issues) and whole-program optimization.

CLaudio Lawira wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 7:41 PM
In order for a cracker to play with your computer:

1. .Net case
Please download this unmanaged code (C++) and just run it.

2. Java case
Please download this code and by the way download this
other code (.dll) if you have Windows and this other
code if you have Linux (.so) and this other code if
you have a MacOS. And then put it in your path please
(so JNI can find it). And then run it in the JVM.


Which one is safer ?


Kannan Goundan (again!) wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 7:43 PM
gipak:

"What would requrire you in java to write JNI? Not mocking, simply asking."

I've only needed to use JNI to interface with C libraries. I'm not saying that JNI use is common. I'm just saying that the need for unsafe code in the CLR is only as common as the need for JNI in Java.

I'm not at all trying to say that JNI is a real security threat. All I'm saying is that CLR unsafe code isn't either.

"if c++ code is portable it probably can be replaced with c# so where is the need for it?"

First of all, some people like the C++ language. Secondly, unsafe code doesn't necessarily mean only C++. You can write "unsafe" code in C# as well.

To call native DLLs from Java, you have to write a JNI wrapper for each library call (in C) and compile it (ahead of time) for each target platform. With C#, the "unsafe" native invocations are kept in portable bytecode form and will be automatically compiled by the JIT when it needs to be run; you don't have to ship around CPU-specific executable code.

With Java, every time you need to do something unsafe, you have to write C code and compile it ahead-of-time for every target platform. With C#, you can sometimes achieve the same effect in a *portable* way by using managed/unsafe code. Both techniques are unsafe, but only the CLR technique is portable.
Kannan Goundan wrote re: Huge Security Hole in Solaris and JVM
on 02-07-2005 9:41 PM
Claudio Lawira:

It looks like you're talking about downloading applications and executing them locally. If you execute a pure Java application locally, it has the ability to erase your home directory. The same goes for a CLR application. Type safety is not an issue here.

If you're talking about untrusted code, unverifiable code can easily be disallowed. Just like Java Web Start asks permission before it lets a program touch your hard drive, a hypothetical CLR Web Start would ask for permissions before it lets a program run unsafe code.

BTW, "unmanaged" code is not portable and so you couldn't just download and run it. It works just like JNI. I assumed you meant "managed/unsafe" instead.
Sonam Chauhan wrote Security of Managed C++
on 02-08-2005 4:32 AM
Hi Don - thanks for your explanation about the 3 code classes.

I was at Gosling's presentation, and from what I recall, he was talking about managed C++... he said support for managed C++ allowed for these security issues in the CLR.

Does what you said about C# and VB.NET apply to managed C++ as well?

Onion Blog wrote Slashdot Server Spike
on 02-08-2005 7:32 AM
Dilip wrote re: Huge Security Hole in Solaris and JVM
on 02-08-2005 8:51 AM

The definitive word on this issue; next only to Don Box in terms of authoritativeness:
http://www.interact-sw.co.uk/iangblog/2005/02/08/goslingmcpp
Lorenzo Barbieri @ UGIblogs! wrote Huge security hole in... Java!!! 2a parte...
on 02-08-2005 9:15 AM
Dan Fernandez's Blog wrote Don Box responds to James Gosling .NET Bashing
on 02-08-2005 9:46 AM
Chris' Comments wrote Don Box responds to Gosling's rants
on 02-08-2005 3:07 PM
Chris' Comments wrote Don Box responds to Gosling's rants
on 02-08-2005 3:18 PM
Patrick Schriner wrote re: Huge Security Hole in Solaris and JVM
on 02-09-2005 2:05 AM
@Charles Moore
I think VM programming is the way to go. Low level programming has only limited use; I think VM language systems as Java or .NET are inherently more secure (And far easier to secure). Security will be one of the most important factors in the next years.

Of course you will never have OS built in managed code, but that´s not as important as having most applications in a contained environment.

I´m a Java programmer (mostly), but I think .NET (more specifically: C#) would be my first option when writing a Windows App. A lot of Shareware / Freeware programmers are going the same way (e.g. most Feedreaders). It´s just way easier to set up a build environment, reuse libraries etc.

On the JNI vs. Unsafe Code issue:
I think JNI is so "out of the Java way of think" that most people can get along without it. The unsafe keyword in C# is far to easy (in terms of learning curve) to use. What should keep a C++ programmer from using it all the time, if he think you can solve problems by pointer arithmetics only? Why bother to use normal OO technique? Most Java IDEs don´t come along with a C or C++ environment, making use of JNI even more unprobable.

Therefore my critic of .NET would be that using unsafe constructs is too easy (For the developer).
IanG on Tap wrote Testing James Gosling's Thoughts on C++ in .NET
on 02-09-2005 9:05 AM
Jeff Ratcliff wrote re: Huge Security Hole in Solaris and JVM
on 02-09-2005 11:13 AM
Patrick:
"I think JNI is so "out of the Java way of think" that most people can get along without it. The unsafe keyword in C# is far to easy (in terms of learning curve) to use. What should keep a C++ programmer from using it all the time, if he think you can solve problems by pointer arithmetics only?"

A major reason why Java has been successful is because most programmers don't want to deal with the difficulties and dangers of pointers unless there's a compelling reason to do so. Using the unsafe keyword doesn't make pointers any easier to deal with.

On the other hand, anyone who is a "pointer freak" (i.e. someone who wants to use pointers gratuitously) is not going to be intimidated by the difficulty of learning or using JNI.
Mono CAS and Verification. wrote re: Huge Security Hole in Solaris and JVM
on 02-09-2005 2:47 PM
Mono today does not implement the Code Access Security, and it is high on our priority list.

Mono 1.1.4 has the CAS engine, but we
have not yet completed an audit, nor
is it ready for prime time.

But long term, we will have the same
security features that are found on
Microsoft's or Sun's VMs.

I was going to write something about
Gosling sticking his foot in his mouth
but someone pointed me to this nice
post from Don.

Miguel.
Anonymous Coward wrote re: Huge Security Hole in Solaris and JVM
on 02-11-2005 1:10 PM
What I like about Don Box is the way he reuses stuff - http://beust.com/weblog/archives/000239.html ...
Don Box's Spoutlet wrote Get Your Verifiable C Here
on 02-11-2005 3:16 PM
Dan Fernandez's Blog wrote re: Responding to Richard Grimes article on .NET
on 03-07-2005 9:28 AM
TrackBack wrote Don Box responde a Gosling sobre el c
on 03-25-2005 6:00 AM
Code: Axure wrote WinFX Coming of Age
on 02-27-2006 10:55 PM
It's been mentioned on several blogs already, but Microsoft, yesterday, announced another CTP (an acronym...
Lexapro. wrote Lexapro when does it work.
on 08-14-2008 3:53 PM

Why does lexapro make me sleep all the time. Lexapro. When do you feel better with 10mg lexapro. Gain weight on lexapro. Lexapro and drinking.

Side effects of lipitor. wrote Generic version of lipitor.
on 08-15-2008 9:28 PM

Lipitor problems. Lipitor side effects walking walking. Lipitor negative side effects. Can i drink wine while i m on lipitor. Generic version of lipitor. Lipitor pricing. Lipitor side effects.

Add a Comment

(required)  
(optional)
(required)  
Remember Me?


home instructor-led training online training blogs

781.749.9238 (East Coast) | 310.251.9901 (West Coast) | Pluralsight, LLC , 185 Lincoln St., Suite 305, Hingham, MA 02043-1741

Copyright © 2008 Pluralsight LLC. All rights reserved.

designed by nukeation