MS Security Guy Wants Vista Bugs Rated Down 167
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."
Re:Its about the bug, not the environment (Score:5, Informative)
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.
Re:Its about the bug, not the environment (Score:4, Informative)
http://gcc.gnu.org/gcc-4.1/changes.html [gnu.org]
Re:Isn't that ..... (Score:3, Informative)
Did you intend those two scenarios to be mutally exclusive?
Rating a bug low does not necessarily mean that it is fixed slower.
Re:Its about the bug, not the environment (Score:5, Informative)
- /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.
They want to do something about security? (Score:3, Informative)
That means getting rid of "Security zones". All documents displayed by the HTML control must be considered "untrusted".
To do this, start by getting rid of the ability for documents viewed in the HTML control to request the use of ActiveX objects, since no documents are considered trusted, ActiveX can't be used anyway.
At the same time, provide a mechanism like IO Slaves for applications to install controls... a mechanism that can not be requested by a document.
Modify Windows Explorer and Software Update to use this application-controlled mechanism to install components into the HTML control.
Create an IE shell that installs an "ActiveX IO Slave" to restore the existing behaviour. This shell will display windows with some visual indication that they are untrustable and dangerous. Users who acually require this functionality during the transition can run the "Insecure IE" shell.
In the next major release of Windows, remove that component.
Re:stop whinning and just.... (Score:3, Informative)
P.S.: Note that OpenSource programs with few developers interested in the code run into this same problem. Good peer review takes lots of eyes in multiple environments over an extended period of time. A structured code walkthrough just isn't the same thing. It helps, but it's not the same.
Re:Isn't that ..... (Score:5, Informative)
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.