Microsoft's Missed Opportunity

Microsoft makes .NET. Microsoft is busy making Vista (almost on schedule even). So why isn't Vista built on .NET? You may not believe the answer.

Way before Vista, Microsoft spent loads of money and intellectual juice creating the .NET framework, which was and remains very much like Java. In fact, it's probably better than Java, since it has the advantage of being designed and built after Java and its creators took advantage of many a lesson learned.

You see, Brian LaMacchia and the other designers of .NET are smart guys. .NET source code compiles to (interpreted) common language runtime (CLR) just as Java compiles to byte code. .NET has a built-in security model just like Java. .NET is type safe just as Java is type safe. And so on. These are all good things lifted directly from advances made in academic programming languages research over the years.

Vista is the next-generation Microsoft operating system, one day destined to take the place of Windows XP. At the moment, it's hard to know what's going to be so great about Vista, but I'm sure Microsoft will think of something. For now, at least we all know that it will be the next big thing.

Said in passing
At the scientifically rigorous USENIX security conference in August 2005, I caught up in the hallway with Butler Lampson after his excellent keynote talk. Butler is a legendary scientist, and he has done plenty of great pontificating about security, privacy, software, and technology. Like many superior computer scientists, Butler now works for Microsoft Research.

I asked Butler why it was that Longhorn (Vista's codename at the time) was not built out of a type-safe language like those available for the .NET framework. He shook his head in dismay and decried the fact that we had let another great opportunity to make a huge impact on computer security pass us by. He said that opportunities like this come only once every decade or so in his experience and that he had seen four attempts to cause widescale adoption of type-safe languages founder on the rocks throughout his career.

The problem, it turns out, is that the .NET builders did not give much thought to providing many of the essential basic building blocks that operating systems construction crews need for their work. Interpreted code has some minor performance issues as well (note that there are many ways to overcome this often overly shrill critique). But the main problem was that the Microsoft OS guys are big C++ users. Getting them to switch over to C# was for these reasons not in the cards.

Type-safety über Alles
The problem is that C and C++ are well known security bug inducing languages. You see, in C about all you can know about how something like a number or an array is represented is that it's made of bits. It turns out that the very same kinds of bits (often times in the very same location) can be looked on as an address or as any number of other structures. You can arbitrarily cast bits about into different representations, sometimes with drastic consequences. This is known as the "sea of bits" problem.

Too illustrate, consider that most payload code in a classic, stack-smashing, buffer-overflow attack is presented to the target program (the one with the broken buffer) as good old input, not dangerous at all. Yet when this input is written in a special place, like, say the return address on the stack frame, all kinds of control flow problems crop up. The last thing most people want is someone wresting control of their program via specially crafted evil input, but that's what we're talking about here.

In a type-safe language like Java or .NET, there are more guarantees about what is what. An integer is always 32-bits (well, at least until those 64-bit chips are done), an array is made up of a fixed set of similar types all in a row, and there are references to objects instead of pointers to whatever based on memory addresses. In case of monkey business, the Verifier is around to make sure that byte code and CLR plays by the rules of type safety.

Type safety is a necessary, but not sufficient, foundation for modern security models like the .NET security model. In fact, if we step into the way-back machine, a number of the spectacular Java security holes that I helped to find 10 years ago involved screwing around with types using the "type confusion toolkit."

By eradicating the "sea of bits" problem, we can make a huge step forward in software security. Abandon C all ye who enter here! The literally hundreds of simple ways to add software security bugs to code that are caused by the use of C and C++ would simply go away.

It's nice to dream
I know a gigantic global switch from C is unlikely to happen tomorrow. According to Butler Lampson, we have at least another 10 years to wait! In the meantime, we'll have to resign ourselves to the use of static analysis tools and get ready for when the next huge opportunity to cause widespread adoption of type-safe systems comes around. You listening, Microsoft? How about building the next operating system on a type-safe platform?

— Gary McGraw is CTO of Cigital Inc. Special to Dark Reading