Bill Joy's Takes on C#

f00zbll writes: "Cnet is running an article by Bill Joy on security and how it relates to C# and Microsoft at large. BJ quotes verbatim: 'C# provides the ability to write unsafe code. In unsafe code it is possible to declare and operate on pointers, to perform conversions between pointers and integral types, to take the address of variables, and so forth.'"

Comments

So what?

[mosch]

Since when does the ability to use pointers mean that something is wrong? C allows a lot of 'unsafe' code to be written, yet we're all using operating systems writting in C, with very little trouble caused by the OS itself.

Sure, it'd be great (for Sun) for everybody to rewrite the world in Java, but in reality nobody can justify requiring 50% higher CPU usage in exchange for the ability to let programmers be careless.

I'm not saying Java is a bad thing at all, merely that C# isn't any worse than C, C++, perl or python. It's a shame when a press release manages to get linked from slashdot's main page, but that's all this is. Sorry Joy, but I'm not buying it.

Re:So what?

[Hiro Antagonist]

There is a gross difference between Javascript and Java; Javascript is an in-brower scripting language with a rather vague specification. Java is a different beast entirely.

Java applets are actually different from Java applications; they don't have the ability to interact directly with the contents of the hard drive, in addition to all of the other limitations running in the JVM. The most malicious things that a Java applet can do are make lots of windows (not a problem on a Unix box), or present false information to the user -- essentially, Java applets are no more harmful than HTML.

I direct you to a pertinent section of the CERT/CC Malicious Web Scripts FAQ:

Should I disable Java applets?

The risk associated with Java applets is significantly different
from some of the other technologies. Java has a robust security
mechanism designed to deal with situations like these that prevents
sensitive information from being disclosed or client information from
being damaged.

However, Java applets written by an attacker can still be loaded
while your are viewing a legitimate web page. The problems that can
arise are similar to those involving the and other HTML
tags. For example, an attacker could develop a "Trojan Horse" program
that presented misleading information and prompted you for a password.
If you failed to recognize the malicious applet for what it was, you
could accidentally disclose sensitive information.

You must make your own determination about disabling Java applets,
based on your tolerance for these risks. If you choose to disable
Java, please see the detailed instructions below.

Trustworthy Code

[SteveX]

You can use C# to write "Unsafe" code, but it's the runtime that ultimately decides whether or not to let it run. For example, if the VM that the browser creates tries to launch a C# app downloaded from the Internet, and it's "Unsafe", the CLR will refuse to run it.

Difference between C# and ActiveX in this case is that in ActiveX, everything is "Unsafe" and you either take it or leave it. In Java, of course, everything is "safe". C# can go either way.

I really hope that Microsoft simply makes it impossible to run "Unsafe" CLR code in the browser. Not even an option.

- Steve

C# FUD?

[glh]

This sounds like FUD. He didn't really post any examples about what kind of problems C# has for security, that would have been helpful.

I think a lot of people are upset because MS has actually come out with something that can compare with Java finally.. The ability to write unsafe (unmanaged is what that really means, meaning the garbage collector and built in memory management features of the CLR won't touch it) is an added bonus to Java.

I think the real question is- how secure is the .NET common language runtime?

FUD machine in overdrive

[coonsta]

To serious developers not familiar with C# and .NET, either don't read Joy, or be willing to look into the details yourself. You could be embarrassed if you repeat the gist of this article as lore. At the very least, you can easily convince yourself that this article is bogus in that it doesn't mention that C# has three kinds of pointers-- managed, unmanaged and transient.

C# does allow pointers and pointer manipulation. This is mostly for programmers seeking extra performance. Like a cast in Java, declaring code as "unsafe" is equivalent to saying to the VM, "Hey, I know what I'm doing." C# pointers are definitely not as liberal as C ones (just like casts in Java are not as liberal as casts in C).

For those sincerely seeking an intelligent discussion of pointers in the CLR, see Gough, J. "Compiling for the .NET Common Language Runtime (CLR)" Prentice Hall, NJ 2002.

Uhhh, its supposed to......

[CDWert]

Uhh, and the problem with this is ???????

All lll allow this, C3 may not be a lll but theyre trying to appeal to the uper end of that segment.

C# allows you to write managed, OR unmanaged code as well, This is an option. As well as the coders ability to write "unsafe" code. YOU MUST INTENTIONALLY flag the code to be written as UNSAFE !

If you dont know what you are doing and choose to do this so frigging what ???

C# has the fundementals of a good language, forget its from MS, if it where from GNU, you;d be eating it up saying look how much better it is. I am looking forward to working with it, the .NET Visual Studio is written in C# itself , it should be pretty thouroughly debugged before its released.

Play with it for a week , if youre a beggining C programmer youll love it, if youre experienced, youll love it for the same reasons, My bet is most of the people bitching havent read or written a single line of C#, if have and dont like it Id like to know explicity WHY ?, Ms bashing aside.......

Sun shouldn't be complacent

[astrashe]

Obviously Bill Joy knows a lot more about this stuff than I do; but I think he, and many of Microsoft's critics as well as supporters, are missing a crucial piece of the puzzle.

Many of the features that have contributed to MS's insecurity were there not because MS's engineers were too dumb to think clearly about security, but because other people decided that there was an overriding business interest that the features would serve.

Specifically, these features usually tend to be part of the MS strategy of leveraging success in one sector into another. If you use office, it makes sense to choose VB as your scripting language. If you know VB, it makes sense to run IIS. That's why there's a VB interpreter inside every office app.

I think that what we've seen from MS is an official change in policy -- they're saying that business considerations now suggest that security should be the #1 priority. They're admitting that the market will punish them for security holes, and that they can't sacrifice security to establish leverage from one sector to another.

MS has always put business concerns over technical ones. For that reason, a lot of /. posters have make comments to the effect that MS isn't capable of delivering technically. It used to be the conventional wisdom here, for example, that any MS OS was destined to crash repeatedly.

It turned out that when MS saw Unix and Linux as a threat, and when they decided that reliability was one of the biggest advantages that Unix/Linux offered, they took reliability seriously and made enormous progress in a relatively short period of time. This suggest that Windows crashed not because MS *couldn't* make it reliable, but because it wasn't a *priority* for them to do so. As soon as they saw a change in the business climate on the edge of their radar screen, they changed their behavior.

Windows and its applications haven't been secure because MS hasn't felt it was worth making security a priority until now. There is no evidence that they couldn't cover a lot of ground very quickly in security if that's what they decided to do. And it seems as if they've decided to do just that.

I do agree that .NET and C# are technologies that predate this new ordering of MS's priorities, and that they probably won't be very secure. Passport, the most important .NET application yet written, coded by people who ought to know the technology best, has been hacked (and patched, it's only fair to point out). If MS's people don't write secure apps with .NET, are the low end VB coders the platform is designed for going to do a better job?

But the problem that Sun faces is that MS has proven time and time again that they're willing to spend lots of money and go through lots of iterations to take a market. They're relentless. They usually don't get it right the first time, but they usually do get it right after four attempts or so.

I'll say something else that will probably get me modded down. After the recent flirtation between AOL and RedHat, I'm not sure that the moralistic arguments against MS hold up so well. Linux has been at the center of some pretty slimey stock swindles -- our gracious hosts, here at /., work for one of those companies.

Meanwhile, the Bill and Melinda Gates foundation is giving extraordinary sums of money to real nuts and bolts making the world a better place kinds of causes. Gates could literally turn out to be the most significant philanthropist in the history of the world. They're giving so much money that you can almost see a chunk of what you spend on MS going to a good cause.

All of which suggests to me that politics and the morality play that have always clouded the linux vs. windows debate should probably be put to rest.

Windows is horribly insecure -- viruses do incredible damage in the real world, especially among the least sophisticated users. That's not political, that's a fact.

But they're saying they're trying to clean up the mess. Sure, it's a big mess, and sure it's going to be a big job to clean it up. I give them credit for admitting it, and to taking on the task.

Where do you get your facts?

[Carnage4Life]

I think the difference is that .NET and C# are designed as a network-based platform; e.g., you grab code off of the 'net as you need it, rather than storing everything locally.

Really??? What gives you this idea? Java + VM is relatively equivalent to C# + CLR (as mentioned in my article that appeared on Slashdot a while ago). Code can be downloaded from the Internet and run just like with Java applets or RMI applications but this is far from the primary design of the platform .

Of all the people in the world I'd expect to criticize a technology without adequately reading up on it first, Bill Joy would have beemn one of the last I'd expect to do such a thing.

Bill Joy (and your post) go on and on about the vulnerability of network programming then ends with the reference to unsafe code which aims at giving the impression that downloaded .NET code can be unsafe. However this is incorrect, and I quote

From a technical viewpoint, the term unsafe refers to whether the program is known to be safe. Before a program is converted from intermediate language (IL) to native code, there's a part of the runtime security system known as the verifier that looks at the IL to determine whether it's safe to execute. In this context, safe means that the verifier can prove that the IL doesn't do anything unsavory.

IL safety is important for certain Microsoft .NET scenarios--it's nice to know that the chunk of code that you downloaded from a Web site isn't going to do anything bad to your machine. The default policy for remote code (either from a Web site or from a net share) is that the code must be verified safe to execute.

In other situations, it's useful to write code that can't be verified to be safe. In C#, any use of pointers generates unsafe code, as does any use of interop, such as COM interop or platform invoke.

Since you don't want to write such code inadvertently, C# requires you to use the unsafe keyword on your class or method whenever you write code that deals with pointers. When you use the unsafe keyword, the resulting IL is marked as unsafe and can only run in a fully trusted environment (usually, security policy only trusts local assemblies). In the current version of the runtime, unsafe is defined at an assembly level, so having any unsafe code in assembly makes the entire assembly unsafe.

Re:Taint mode?

[crawling_chaos]

Two words: buffer overflow

A "taint" mode would do nothing to catch these. Perl doesn't let you manipulate pointers and storage directly, so it's no big thing there. C#'s unsafe mode code does, and that's the big problem.