Digg this story   Add to del.icio.us  
Memo to Microsoft: Stay Secretive, Please
Jon Lasser, 2002-05-15

Unix and Linux security owes much to openness and public disclosure, but Microsoft is too far gone for sunshine to do any good.

Last week Microsoft VP Jim Allchin raised a fascinating new argument in the company's ongoing anti-trust drama when he claimed that Redmond needs to keep some security-related protocols and APIs secret from the public because disclosing them would make Microsoft's products vulnerable to hackers and virus-writers.

Of course, even with these details kept secret today, there's no shortage of attacks against Microsoft operating systems containing these features. But this "security through obscurity" argument is as natural to Microsoft as it is anathema to open source types like me.

But I'm now ready to throw in the towel on this debate. Maybe Allchin is right: Microsoft's security record would be a whole lot worse if they were forced to disclose too much.

I know... It's tempting to think that more disclosure would make Microsoft more secure. After all, the strongest security records in the open source community are clean by comparison to Microsoft's. If it works for us, why not for them?

But the open source development model, with full disclosure of known vulnerabilities and extensive peer review, is not a panacea, and can't necessarily be used to fix flaws while retaining backwards compatibility -- especially in cases, like Microsoft's, where it's the design and not the implementation that suffers from bugs.

Perhaps the best example of open source security is OpenBSD. But in recent years there have been exploits against OpenBSD's FTP daemon, against core system utilities, and (less surprisingly) unfortunate interactions between popular third-party packages shipped with the operating system.

OpenBSD's once-grand claim of no root exploits in so many years has been reduced to "no remote root exploits in the default installation." Given that virtually nothing is enabled in a default installation, this claim is certainly likely to stand.

The OpenBSD team is pretty much the best there is, but security is difficult. It's difficult even when you have a small, well-disciplined team chock-full of smart people working closely from well-written specifications and dedicated to security above most other goals, including commercial success.

Now, think of Microsoft.

Moreover, one the major security advantages of open source development will always be out of reach of Redmond. I don't mean the "many eyes makes all bugs shallow" argument that Eric Raymond makes in The Cathedral and the Bazaar, and which I'm not sure I believe, but rather one of the subsidiary arguments which receives less attention: that open source code is less likely to have major flaws because programmers are substantially more careful when they know that other people will be reading their code.

Confusion and Bloat
Microsoft coders will never find this a motivator. As a public company, Microsoft is driven by the bottom line. They have thousands of programmers scattered across the globe working to produce large, monolithic applications that must ship on time and integrate with every other Microsoft application.

The applications themselves are driven at least as much by strategic corporate initiatives designed to maintain industry hegemony as by customer needs or internal design considerations. Witness the Windows Server family's feature set, which has for years oscillated between trying to put Novell out of business, trying to put Sun out of business, and being a platform for building business applications that run over the Internet.

It's a virtual certainty that all of Windows' internal APIs and protocols suffer from confusion and bloat. Even their publicly documented bits are a mess that the Microsoft Foundation Classes can't really hide.

In all likelihood, the most serious Windows exploits are not the buffer overflows we've grown accustomed to patching. Instead, they're more fundamental flaws, like the password hashing weaknesses that L0phtcrack exploits, or the PPTP design flaws that Counterpane discovered back in 1998.

Just as it would be a dreadful idea for Microsoft to release Windows source code in its current form, it would be disastrous for them to release the Windows specifications. The current specifications are, clearly, no basis for a secure system.

Until Windows has been redesigned from the ground up, complete with peer review of all core architecture, not much can be done to stop Redmond's gaping, oozing security flaws from festering like wounds.

Jim Allchin is right. Microsoft's designs should be kept under wraps... not for their protection, but for ours.

SecurityFocus columnist Jon Lasser is the author of Think Unix (2000, Que), an introduction to Linux and Unix for power users. Jon has been involved with Linux and Unix since 1993 and is project coordinator for Bastille Linux, a security hardening package for various Linux distributions. He is a computer security consultant in Baltimore, MD.
    Digg this story   Add to del.icio.us  
Comments Mode:
...Until Microsoft redesigns from the ground up 2002-05-16
Matthew Kauffman (2 replies)
...Until Microsoft redesigns from the ground up 2002-05-16
Anonymous (2 replies)
...Until Microsoft redesigns from the ground up 2002-05-20
manually adding html tags to be safe (1 replies)
Memo to Microsoft: Stay Secretive, Please 2002-05-16
Not Really Anonymous (1 replies)
Memo to Microsoft: Stay Secretive, Please 2002-05-17
blane (1 replies)
RE: Memo to Microsoft: Stay Secretive, Please 2002-05-17
Not Really Anonymous (1 replies)
Another Linux/Unix Apologist Overlooks the Obvious 2002-05-16
Anonymous (7 replies)
Another Victim Overlooks the Obvious 2002-05-16
Anon (1 replies)
Another Linux/Unix Apologist Overlooks the Obvious 2002-05-17
Anonymous (1 replies)
Another Linux/Unix Apologist Overlooks the Obvious 2002-05-17
Anonymous Unix Gal (1 replies)
Let's Be Real 2002-05-21
Memo to Microsoft: Stay Secretive, Please 2002-05-21
blacklight (1 replies)
Another attempt at trying to get fired 2002-05-24
Someone fire this guy :\


Privacy Statement
Copyright 2010, SecurityFocus