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
20 Questions to Ask Yourself before Giving a Security Conference Talk
Joshua Goldfarb, Co-founder & Chief Product Officer, IDDRA,  10/16/2017
Why Security Leaders Can't Afford to Be Just 'Left-Brained'
Bill Bradley, SVP, Cyber Engineering and Technical Services, CenturyLink,  10/17/2017
Secure Wifi Hijacked by KRACK Vulns in WPA2
Jai Vijayan, Freelance writer,  10/16/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Security Vulnerabilities: The Next Wave
Just when you thought it was safe, researchers have unveiled a new round of IT security flaws. Is your enterprise ready?
Flash Poll
The State of Ransomware
The State of Ransomware
Ransomware has become one of the most prevalent new cybersecurity threats faced by today's enterprises. This new report from Dark Reading includes feedback from IT and IT security professionals about their organization's ransomware experiences, defense plans, and malware challenges. Find out what they had to say!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.