From: Russ (Russ.CooperRC.ON.CA)
Date: Fri Jun 04 2004 - 11:26:50 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

A vulnerability does not infer exploitability, there are many vulnerabilities which Microsoft has chosen not to correct with Security Bulletins simply because they could not be exploited directly, only via some other compromise.

The severity of a vulnerability is entirely subjective. If I'm a home computer vulnerable to blaster, I probably have it already. Take the same computer and place a personal firewall on it and I'm no longer exploitable, albeit I'm still vulnerable. The severity of the RPC vulnerability which led to blaster varied greatly. If I had DCOM disabled, for example.

The security of a given system isn't dependent on vulnerabilities either. I could have a completely secure mail client, yet it would still be possible for a user to receive a PGP signed and encrypted attachment, save it to disk, then double-click on it and become owned.

Finally, a given security bulletin, and/or its associated patch(es), often refers to more than one vulnerability.

IOWs, vulnerability, exploitability, severity, and security, security bulletins and patches are all different things.

I analyzed vulnerabilities, and security bulletins, only.

My purpose was as follows;

1. The media is constantly reporting on Microsoft security efforts during reports on vulnerabilities and/or security bulletins. Reports about new worms, viruses, or other malware usually refer to the security bulletin which fixed the underlying vulnerability the malware exploits.

2. From a purely numeric perspective, I've never seen anyone cite anything other than the count of bulletins when discussing quantities of MS security issues. I have long seen the quantity of vulnerabilities as being a far more relevant number.

3. I have often seen security comparisons between Windows and, say, Linux. I have long stated that these comparisons are flawed, they aren't apples to apples, because the two systems aren't configured with equivalent functionality. A default MS server contains far more than a default Linux server. I felt it would be better if we talked about systems from their functional perspective, so I assigned vulnerabilities to "Server", "Desktop", or "IIS" categories. When I did this, I included all of the products that are installed by default on such a system (although I did create a category for W2K server which did not include IIS, something you can't get by default.) OE, IE, Media Player, VM, MDAC, (not MSDE), were all included, even on W2K3. That these things "should never be used" on such systems is irrelevant from the perspective of my analysis. If the code's present, or automatically installed, and its vulnerable, then the containing system is vulnerable. I did separate components which could be removed from those that couldn't, but this was not shown in my analysis.

Now to clarify a couple of other points;

- We do not believe that people shouldn't patch. We believe that people should patch appropriately.

- We do believe that, in many companies, patching creates a false sense of security. Patching is almost always the last thing on a TruSecure list of things to do when a vulnerability is discovered or its patch announced. The reasoning is simple, you can spend a lot less time doing other things which will have a greater effect on your overall security than applying a patch will. Far too many companies don't do other things, such as default deny, and instead rely upon, or believe completely in, the effectiveness of patching as their primary mitigator against threats. Since 100.0% patching is extremely difficult to achieve in *larger organizations* (e.g. not SBS-type orgs, orgs > 100 systems), you can still have your network saturated by, say Slammer, if you miss a single box.

- In the Sasser survey we performed, we found that sites which made no attempt to patch had less infections than those who tried but did not achieve 100.0% application. From this I extrapolated that sites which made no attempt had mitigated the risks of Sasser in other ways, and therefore didn't need the patch.

- To the issue of patching being a waste of resources, by and large it is. The vast majority of patches correct vulnerabilities which are never exploited. Wouldn't we all love to know ahead of time which patches will result in an exploit, and then just apply those patches? Wouldn't you agree that such knowledge would avoid wasting resources on unnecessary patch deployment? Well, we a TruSecure believe this is something which can be achieved, with adequate knowledge, analysis, and appropriate mitigators (alternative/additional layers of security.) We certainly don't believe that every company can do this on their own.

- To my points about the effectiveness of Microsoft's security push. I feel that we should, by now, be seeing far more examples of vulnerabilities which simply are not present in Windows Server 2003. There have been some, but in my opinion, not enough to convince me the security push/code review has yet yielded significant results. I hope we see this with Longhorn, but it wouldn't surprise me if we continue to see a significant number of legacy vulnerabilities in it too.

Finally, I've not yet decided whether or not I will release the details behind the numbers. The methodology I used is simple enough, and the data is all publicly available on Microsoft's site. However, since the IIS 6.0 numbers seem to be the most contentious, I've included the list of bulletins below and the number of vulnerabilities from each which give me the number 60. I'll be happy to argue their applicability off-line.

The thread has probably gotten old already for most subscribers, so unless there's a significantly new contribution we'll end it here.

Cheers,
Russ - Security Guru of Microsoft Technologies - TruSecure Corporation
(I loved the dictionary definition of Guru! - thanks Mike Liddekee)

MS03-004 (2 vulnerabilities)
MS03-014 (1 vulnerabilities)
MS03-015 (7 vulnerabilities)
MS03-017 (1 vulnerabilities)
MS03-020 (2 vulnerabilities)
MS03-026 (1 vulnerabilities)
MS03-032 (5 vulnerabilities)
MS03-033 (1 vulnerabilities)
MS03-034 (1 vulnerabilities)
MS03-039 (2 vulnerabilities)
MS03-040 (3 vulnerabilities)
MS03-041 (1 vulnerabilities)
MS03-043 (1 vulnerabilities)
MS03-044 (2 vulnerabilities)
MS03-045 (1 vulnerabilities)
MS03-048 (5 vulnerabilities)
MS04-001 (1 vulnerabilities)
MS04-003 (1 vulnerabilities)
MS04-004 (5 vulnerabilities)
MS04-006 (1 vulnerabilities)
MS04-007 (1 vulnerabilities)
MS04-011 (8 vulnerabilities)
MS04-012 (3 vulnerabilities)
MS04-013 (1 vulnerabilities)
MS04-014 (1 vulnerabilities)
MS04-015 (1 vulnerabilities)

-----
NTBugtraq Editor's Note:

Want to reply to the person who sent this message? This list is configured such that just hitting reply is going to result in the message coming to the list, not to the individual who sent the message. This was done to help reduce the number of Out of Office messages posters received. So if you want to send a reply just to the poster, you''ll have to copy their email address out of the message and place it in your TO: field.
-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]