MS Security Guy Wants Vista Bugs Rated Down
jcatcw writes "Gregg Keizer reports that Michael Howard, an MS senior security program manager, says that the Microsoft Security Response Center (MSRC) is being too conservative in its Vista vulnerability rating plans. Microsoft's own bug hunters should cut Windows Vista some slack and rate its vulnerabilities differently because of the operating system's new, baked-in defenses."
Note that OpenBSD is also adopting similar defense-in-depth strategies, including SSP and N^X. Adoption is much more haphazard on Linux Distros, so you may be at much more risk running an application such as SSH on Linux than on OpenBSD even when it is compiled from the same source code.
http://gcc.gnu.org/gcc-4.1/changes.html
- /GS. In theory works fine. In practice, you MUST (1) get the software publisher to compile with the switch, (2) cannot use inline assembly (/GS bails out on such code), and (3) must be willing to sacrifice a small bit of performance. In other words, a fair amount of real-world code can't use this. And oh by the way, this doesn't protect against all buffer overflows - it only protects against the easiest category. It's still quite possible to corrupt data with a buffer overflow, and maybe use that data to gain control.
- /SafeSEH. Right
... how many common languages don't have good exception handling? You said C only, right? And how often do you use Windows exceptions in C? Not much, you say? When I've seen SEH code, it's almost always very narrowly scoped and thus easy to get right - in real code, Windows SEH is just a trampoline to get into another exception mechanism. Making it "safer" adds no value.
- ASLR. This one makes generating a sucessful exploit a little more difficult - moves it from medium-easy to medium, because it's harder to hit a "target buffer". Of course, for compatibility reasons, a fair number of apps turn this off (they have assumptions about where code lives, and/or need the wasted address space). It helps - statistically. But a lucky guess is still going to succeed, and I don't trust luck for security.
- DEP. A two-pronged technology, which (1) uses the NX bit and (2) disallows syscalls from data segments. Oh but wait, (1) requires having a fairly recent processor and (2) is fine for some apps, but breaks for anything that does dynamic code (e.g. a Java runtime), so it's also disallowed for many, if not most, apps.
So what do we find out from this list? You get defense-in-depth - IF you are running the latest hardware, IF you use only software built with MSFT's favorite options (some of which are opt-in), and IF you only run apps that embrace all these strategies. How many Joe Consumers fit into those ifs? Datacenters might be closer, but I'll bet even they can't generally say all these hold true.I'm glad open-source is adopting some of these measures. But let's be realistic - all any of these technologies do is make a sieve less leaky by putting a second sieve underneath. Something is nice, but we would be fools to treat any of these security "features" as more than a speed bump.
A witty [sig] proves nothing. --Voltaire
To give some context to who Michael Howard is, he is one of the head security guys at Microsoft. One of his roles is to improve the development process across Microsoft to improve security. So the MSRC responds to actual security vulnerabilities, while Michael looks at why the development team missed the bug and how to avoid it in future products.
If you read what Michael actually said the issue becomes more apparent. A security bug that affect Vista and XP will usually be given the same rating, even if Vista has defense mechanisms that it make it extremely unlikely that it can be exploited. In the security alert they will list any defense mechanisms that make it harder to exploit the bug, but they don't change the rating.