Bloomberg Anywhere Remote Login Bloomberg Terminal Demo Request


Connecting decision makers to a dynamic network of information, people and ideas, Bloomberg quickly and accurately delivers business and financial information, news and insight around the world.


Financial Products

Enterprise Products


Customer Support

  • Americas

    +1 212 318 2000

  • Europe, Middle East, & Africa

    +44 20 7330 7500

  • Asia Pacific

    +65 6212 1000


Industry Products

Media Services

Follow Us

Bug-Zapping, Microsoft Style

By Alex Salkever Looking for a tough job? Try Mike Nash's. He's the executive in charge of Microsoft's "Trusted Computing" initiative charged with building more secure software. Nash has the unenviable task of taking on Redmond bashers who decry Microsoft's lax security. And he has to convince the world that, yes, Virginia, Microsoft products are secure.

It may be ugly, but Nash has taken this one on with relish, leading brown-bag breakfast lectures on security topics at the Microsoft Campus and, by his account, infusing the new religion of security into every corner and cubicle of the software-development process. When I wrote a piece criticizing Microsoft's latest operating system as suffering from the cardinal sins of complexity and code bloat (both of which promote vulnerability) in late April, Nash called me to respond and give me his take on why Microsoft (MSFT) products are a lot more secure these days and probably should be getting more credit (see BW Online, 4/29/03, "For Windows, Less Fat Means Fewer Bugs").

It was an interesting conversation, and he made some good points. So in the interest of fairness, this week's column will probe Nash's point of view on this hot topic.

CAN'T KNOW IT ALL. The argument that code bloat means less secure software is based on simple mathematics. Complexity rises very quickly for each additional element added to any system or equation. With complexity comes vulnerability, because mere mortals -- even the brainiacs at Microsoft -- have a hard time wrapping their minds around millions of lines of code. In fact, no one disputes that it would be truly impossible right now for any human being to have an effective working knowledge of all the parts of a complex operating system, be it Windows, Unix, Linux, or Apple's OS X.

The way society and business have thus far conquered complexity is through automation and process controls. Engineers don't have to use slide rules to calculate tensile strength required of cable strands on suspensions bridges because sophisticated computer programs do it for them. Likewise, space flight is possible only through rigorous processes that harness hundreds of individual minds into a disciplined whole.

Nash argues that Microsoft is now using both approaches to mitigate complexity risks inherent in big software. And he says Microsoft is already producing much safer products because of new automated tools to spot bugs and better processes to emphasize software security.

FLAW FINDERS. Here's a thumbnail sketch of his points. Over the last year, Microsoft has begun more extensive use of programs designed to automatically detect bugs in code. One is called PREfix, and the other is called PREfast. Both were developed by the folks at Microsoft Research, and both use complex algorithms to search for software constructions that will likely result in flaws.

PREfix was first used to find problems in Windows 2000 code, but Nash claims it's greatly improved and has been used more proactively in more recent software-development processes. PREfast is a smaller, less complicated program that software developers can use to pinpoint obvious bugs. Microsoft developers employ it to vet their code, and Nash says outside developers are also starting to use PREfast.

As for process, Microsoft's big initiative to train all its software engineers in secure software design got wide publicity. The company halted all code development in early 2002 for several weeks to put everyone through the training. Microsoft also changed its code-checking process. Rather than having dedicated security engineers come in after the fact and clean up the code -- a process that can be disruptive -- Microsoft chose to designate a lead security person for each component of the Windows source code.

GIVE SERVER A CHANCE. "From a process perspective, we have provided accountability to all parts of the operating system. We created specific accountability system so that we know every component of source has a developer responsible for the security quality of that source," says Nash.

Neither concept is entirely new. Researchers have been working on automated bug-fixing tools for years, although they're particularly hard to build because distinguishing bad code from good code is often a matter of taste and opinion, and closing one type of vulnerability can open another. Sun Microsystems (SUNW), IBM (IBM), and other big software shops have long followed similarly rigorous security mechanisms, and they've been rewarded with reputations for relatively strong security.

Nash argues, however, that the people who bash Microsoft should give Windows 2003 Server a chance because it's the first generation to really reap full benefits from Redmond's new tools and process.

MULTILAYER SECURITY. Microsoft has has made one giant step by eliminating one of its biggest security bugaboos: It now ships its latest operating system with many key capabilities turned off by default. That means Joe User booting up his system for the first time won't automatically launch Windows' built-in Web server and open his machine to the Internet at large without realizing it. More important, Nash claims that the Windows development team has built in precisely the type of multilayer security that hardcore security engineers have long advocated.

That's no small feat. Nash points to a particular vulnerability reported in Microsoft Security Bulletin 03-007. This was a way that a malicious hacker could type in an extremely long URL into a publicly accessible portion of the Windows 2000 OS, crash the system, and possibly take it over. Microsoft issued a fix for that program some time ago.

But as an academic exercise, Nash and his team examined Windows 2003 Server with regard to the vulnerability described in 03-007. They discovered that even had the flaw been present, Microsoft's secure development efforts had broken a series of weaknesses that would have allowed 03-007 to escalate to a much more serious level. That's because in Windows 2003, the input fields for URL commands for key programs used to share and develop Web sites are just 16 kilobytes, much shorter than the 64 kilobytes required to execute the 03-007 vulnerability. And the piece of software that allowed a hacker to take over the whole OS after exploiting 03-007 runs in a much more protected manner in Windows 2003.

Translation? It's much harder to get the keys to the OS's inner sanctum, even if you can break in the front door. "It comes down to a realization that we need to do at multiple levels everything possible to make vulnerabilities go away so that even if they do exist, they don't cause a problem," says Nash.

EXPOSED KERNAL? Of course, that's Nash's version. Some security experts who often critique Microsoft products have pointed out that Redmond's decision to move the Web server portion of Windows into the OS's "kernel" could be a recipe for disaster. The kernel is the inner core of the OS. As such, it controls the system's most basic functions. So hackers accessing the kernel by any means can usually exert significant control over the entire system. The security advocates worry that putting into the kernal a part of the OS that must interface with the public Internet means you're exposing at least one part of the kernel to all the hackers on the planet.

Further, Microsoft remains in the security doghouse for its slow response in fixing some security holes. That may or may not be fair. Open-source advocates love to claim that many vulnerabilities reported in Linux and other open-source software are quickly tackled by the coder community and often fixed in a matter of hours. In many cases, that's true. But Jonathan Schwartz, the executive vice-president of Sun's software group, has told me that on several occasions when he has reported bugs to a prominent Linux vendor, it told him it didn't know when it would be able to get a fix out.

Schwartz is hardly a disinterested observer, but I did see the e-mail exchanges, and, well, he certainly made his point. Worse than claims of tardy responses to some bugs is the bad reputation Microsoft has gotten for its own security patches that break systems. As a result, many Windows systems administrators take a wait-and-see attitude before applying a patch on the logical theory that a running system, even if it's vulnerable, is better than a crashed one that brings a company to a halt.

BAD BUG COUNT. On balance, however, Nash has outlined extremely positive steps. But he says don't take his word for it. He points out that if you tally serious vulnerabilities, Microsoft fares better by some measures than either Linux or Sun.

Take CERT Advisories. CERT is a federally funded computer-security research center at Carnegie Mellon University in Pittsburgh, and it functions as an information clearinghouse and early-warning system for the computer-security field. CERT advisories are used to call attention to significant threats to Internet infrastructure.

Microsoft operating systems had 5 CERT advisories in 2002. Sun's Solaris OS had 12 during that same period, and Red Hat's Linux distribution -- the leading Linux variety -- also had 12. For all software products grouped by vendor, Microsoft had 7, and Sun had 13. All open-source software had 22. "You can find this on the CERT site," says Nash. "It's all there."

One can certainly dislike Microsoft for its strong-armed marketing tactics. But it's getting harder to fault Gates & Co. for lack of effort on the security side. I'm still not convinced that so much code in one place won't ensure problematic vulnerabilities, but I do believe Microsoft is burning the midnight oil trying to prevent them from happening. Salkever is Technology editor for BusinessWeek Online and covers computer security issues weekly in his Security Net column

blog comments powered by Disqus