I've been working on the publication of a Windows Vista exploit that targets User Account Control (UAC), the part of Windows Vista that prompts users to explicitly grant administrative approval whenever a privileged operation takes place. Once I finish my whitepaper and proof-of-concept code for it, I'll submit it to Microsoft and give them a week before I publically disclose it to Bugtraq. Why am I giving them only a week to respond to it? Because in Microsoft's mind, it doesn't seem to be a "security" issue at all; according to the 10 Immutable Laws of Security, it shouldn't be an issue.
The exploit requires a non-administrative user to execute a non-elevated program in order to infect the target machine. It could potentially be stopped by Windows Defender, although that route would require rather sophisticated heuristics. And it could most definitely be stopped by UAC in a rather straightforward and easy way, but I don't foresee Microsoft making such changes in the near future (when the exploit is published, I will address it in the whitepaper; keep an eye on the blog for the publication).
In the review of the 10 so-called "immutable laws" of security, Microsoft takes a stance that is utter nonsense. Some of it stands up to criticism, of course; but there are gaping holes and hypocrisy in Microsoft's standpoint.
Law 1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore.
Come on, now; if this was a truly "immutable law," then Microsoft wouldn't have needed to implement UAC or PatchGuard in Windows Vista. After all, when people call up Support, they can simply tell the customer, "You ran a program from a bad guy and consequently the computer isn't yours anymore. We aren't obligated to deal with this issue."
People run code that isn't fully trusted all the time. Why? Because there simply isn't a way to sandbox individual applications, even if you wanted to. I hate the fact that I've got to have the Java runtime on my machine, not because I dislike Java, but because there's next to nothing I can do to prevent it from running in the background in any intuitive way. Imagine if I could sandbox the application! It only runs when I want it to. If only.
Furthermore, exploits can be combined. I'll use SmartFTP as an example because it is an Authenticode-signed program that produces a different UAC dialog than Windows when it is being elevated to administrative privileges. If there is a security vulnerability in SmartFTP that permits remote code execution, the bad guy no longer needs to persuade me to run his program on my computer.
It's really a catch-all to say that programs that can't be fully trusted, such as those that are unsigned and come from people you haven't met, shouldn't be run. And it's a weak one. After all, iexplore.exe and windbg.exe are unsigned.
Law 5: Weak passwords trump strong security
This is more of an aside than an outright criticism, but this shouldn't be listed as an "immutable law." A novice administrator might say, "Hey! Let's require 12-character passwords with any combination of mixed-case alphanumerics and symbols!" I believe the Windows Server 2003 password length limit is set by default to policy to 14 characters. Why? After a while, long, strong passwords can actually cause a higher rate of collisions. As developers, we need to be aware of the security considerations involved in the security mechanisms we're implementing. MD5 is a rather trivial hash to break, and as SHA-1 has had its complexity mathematically reduced as well, it's likely we'll see more effective attacks in the near future.
Law 8: An out-of-date virus scanner is only marginally better than no virus scanner at all.
Talk about shooting fish in a barrel. I'm unsure I even understand the purpose of including this "law" in this list.
I appreciate where Microsoft is coming from on this standpoint, but viruses are going to infect computers as long as people are around to use them. Sandboxing a virus, much like certain write operations in Windows Vista are virtualized, would be an effective countermeasure to viral activity, since there's an effective limit to the things that can be done that would be really annoying. Still, people run software they get in their e-mail, that they find on the web. And undoubtedly, the garbage that they get from downloading torrented, illegal software.
That's not the worst of it. Legitimate software, such as Daemon Tools, can come packaged with certain spyware/adware. Daemon Tools, which I just mentioned, comes with the WhenU SaveNow installer, which runs every time Daemon Tools starts up. The only way I could get it to stop nagging me, in fact, was to set the file's security settings to Deny Execute. All told, anti-virus software is not going to block a substantial portion of the malicious software I get.
Law 10: Technology is not a panacea
Granted that most people won't recognize this, anyone who's watched Star Trek for more than a couple episodes should know that this is true. People are constantly defeating the "state-of-the-art" security systems on every different type of computer, which is why the security officers are always busy.
Required-for-plot-movement remarks aside, I've never encountered an end user who thought that technology was a panacea. Almost universally, non-technical people think that computers cause a lot of problems, and technical people, particularly the ones who need to clean up after the non-techies who broke their stuff already know better. Chalk this up to "filler."
All told, some of the "laws" hit it on the head, particularly the notes on physical access to your computer and uploading programs to your website, as well as the computer administrator's trustworthiness and encrypted data security. Still, Microsoft's labeling of these "laws" as "immutable" truly shows that, even their big security push in the first years of the 21st century hasn't taken hold throughout their organization. It is something of a departure from the attitudes expressed in Writing Secure Code (an outstanding read), and I hope that they realize that in the coming future, security vulnerabilities will be more exercises in social engineering than technical issues. With all the work they've done to securify Vista, including Address Space Randomization (ASR), UAC, PatchGuard, stack hash checks, and the like, it will be increasingly difficult to exploit issues such as buffer overflow vulnerabilities, leaving the onus more on the user to break his or her own computer.