Security Watch

The Microsoft Security Debate, Part One

Two users critique Microsoft's understanding of security.

• By Keith Ward
• 02/18/2004

I received some terrific feedback, with strong, substantive arguments about Microsoft's security shortcomings. My original purpose was to pick the best critique and have regular columnist Roberta Bragg respond to its arguments. But there are two that Roberta and I feel are specially deserving, so we're printing both of those today, and I'll post Roberta's response next Monday.

I received so many good essays, however, that I'd like to get more of them published. Look for information on that in an upcoming Security Watch.

Security at Microsoft is a "Fad"
By Robert Michael Slade

Security is currently a bit of a fad in the marketplace, and definitely within Microsoft. Microsoft is rather big on following fads. This is easy enough to see when you are extremely old. I remember "Bob." I remember OS/2, and when Microsoft and IBM were best buds. I remember Microsoft Anti-Virus. I remember Windows 1. I've seen the Trusted Computing Platform initiative (a hardware-based PKI with no provision for certificate revocation) and Palladium. I've seen fads come and go at Microsoft. I have very little expectation that Microsoft has the sticking power necessary to do the long, hard, boring work required to produce programs, mindset, and corporate culture central to real security.

Security isn't a "one-off" deal. It takes time. And when you're retrofitting, it takes exponentially greater time. I'm not just talking about retrofitting products and systems, although that is true as well. I'm talking about retrofitting the company itself: The practices, procedures, mindset, attitudes, official policies, and the unofficial and unwritten ones that actually rule what goes on. I'm reliably informed that Microsoft has had an official policy, for at least the past eight years, stating that all input buffers must be crafted in such a way that the dread buffer overflow is a thing of the past. (It can be done.) And yet we see buffer overflow conditions being introduced time after time. These are not old buffer overflows inherited from legacy code, either. Just recently we have seen the release of a patch for yet another buffer overflow. Actually, I don't have to install this patch. Dinosaur that I am, I am using a really old version of Windows. The vulnerability was introduced in a file that was released (irony of ironies) as a security patch that was developed long after my version of Windows. (After the last service pack for my OS, in fact.)

(There has been much discussion in regard to the latest ASN.1 buffer overflow, about the delay of six months in releasing the patch. Unconsciously borrowing a line from John Calvin, a Microsoft apologist has said that this delay proves Microsoft is committed to security: Look at how long they took to test the patch! It took that long to fix because every part of Windows, and every application, affects every other part. Excuse me, but that is yet another nail in the Microsoft security coffin. Simplicity is security. Least common mechanism is security. Complexity, obscurity, and labyrinthine structure are problems.)

Let's go back to retrofitting. Security is really an add-on to Microsoft products. Yes, in the operating systems based on NT (Windows 2000, Windows XP, Windows Server 2003) you can see the traces of the VMS security core (as well as increasing accretions of UNIX ideas). But there isn't the central security framework that there was in VMS and is in UNIX. Secure operating systems (and secure systems) have a clearly recognizable and identifiable security structure, simple and elegant. Windows, and other Microsoft products, have an ad-hoc collection of security-related gizmos and gadgets. This includes, strangely enough, the various security management tools. The simple fact that there are so many tools for managing security is rather telling.

Which leads to a rather major point. Security is a people issue: Always has been, always will be. The Microsoft user interface with regard to security, on pretty much every product, is a nightmare. Important settings are buried in a bewildering variety of locations. Explanations available in regard to the effects of various settings are incomplete at best, and frequently misleading. Products are configured, and patches are issued, with a "trust us, we know best" attitude. To be most charitable about the ultimate outcome of this position, it completely ignores the fact that people have different needs with regard to security. More realistically, some of the choices defy any kind of reasonable explanation. A while back, Microsoft's answer to an early version of the "iframe" vulnerability was not to disallow auto-execution of programs, but to delete, without reference to the user, any file with an executable extension. More recently, the response to malformed or obfuscated URLs was not to inform the user, but to disallow the "username:password" structure that had become commonly used—and then, without much fanfare, to reinstate the capability. The tortured logic underlying these decisions has to relate, in some way, to the interface design that seems to completely ignore any studies in human factors engineering.

Can Microsoft products be made absolutely secure? No. But then, neither can anything else. Can Microsoft products be made secure enough? Yes. Is it difficult? Yes indeed! Is Microsoft working on security? Currently, indications are that Microsoft is. Does Microsoft "get" security? History and current actions demonstrate that Microsoft has made, and is making, serious and basic errors in regard to security design and practice, and, overall, one has to say that Microsoft still hasn't gotten it.

Microsoft is Confused About Security
By Martin Levasseur

There are a million things I'd like for Microsoft to change about security. I've done jobs involving security myself, and have held numerous positions with security responsibilities, including network administrator; software tester; software designer; and onsite engineer. I'm competent with Solaris, Windows, Linux, Unix in general.

Microsoft just doesn't get it because they're doing things that are only limiting and confusing their OS/customers/developers:

• They still don't understand that they should shut down useless services by default, and not just rehash port numbers.
  
  
• They're creating too many Windows versions. They should create one Windows and stick with it, understand it and master it; then not let the marketing department try to sell it under a new name every year or two by rehashing and re-merging all the modules together with some new functionalities. That's when the security issues appear or reappear.
  
  
• Users, for their part, should also stay with one Windows version and become as familiar with it as possible, so they can sense when problems might be security-related. By having to get used to a new Windows version every year, they get confused again. They assume the new version is better quality/better software, but they're often surprised.
  
  
• Microsoft never scales their products to [the enterprise]. How many times have we seen old features reappearing with the same problems as before, but with a fresh new interface? I suspect there are a lot more artists at Microsoft than actual core developers and testers. Or perhaps the core developers are retired, and [current developers] wouldn't dare touch the kernel code without heavy protections.
  
  
• NTFS is the worst file system I've seen. Security is easily overruled by Linux NTFS mounts. WinFS (already another file system?) is going to be the same thing, I'm sure. The worst thing is that it blocks me as an admin. I can't repair a Windows installation from DOS anymore (when a Blue Screen of Death appears after using Windows update) from a good old Windows 98 boot disk, and can't make reliable backups with utilities like Norton Ghost. And Microsoft goes as far in its arrogance as selecting NTFS by default when installing Windows, forcing everyone to use it.
  
  
• Microsoft is doing things that are supposedly enforcing the use of the GUI, but the company itself isn't even following it. Just look at MS-DOS, which is—thank God—still a part of the Windows OS. How many times has it saved my life, or permitted me to bypass stupid security measures that have been implemented? How many times have I seen patches opening a DOS window for a brief second, bypassing the new security features, in order to give the impression the software is working?

I think that while Microsoft is getting more and more confused and wondering where they're going today, the more the Unix/Linux movement is freeing everybody from those limitations and getting a clear picture of where they want to go in the future.