Risk
5/3/2006
08:25 AM
50%
50%

Microsoft's Missed Opportunity

Software maker shuns its .NET progeny and its type-safe environment in Vista

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

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Security Technologies to Watch in 2017
Emerging tools and services promise to make a difference this year. Are they on your company's list?
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7445
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

CVE-2015-4948
Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

CVE-2015-5660
Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

CVE-2015-6003
Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

CVE-2015-6333
Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.