In looking at Cert's security vulnerabilities summary for 2005 last week I pointed out that they have a tendency to be remarkably over enthusiastic when counting Unix and related applications vulnerabilities. Today I'd like to look at the other side of the coin: are they equally enthused over Microsoft's vulnerabilities?
There is some surface comparability. For example, both the Unix and Windows lists focus mostly on applications and both lists contain duplicates, about 18% for Windows and 62% for Unix.
On the other hand a quick review of the Microsoft side suggests that there are three main problems with that list:
For example, if you search Mitre's CVE database for Windows 98 vulnerabilities discovered during 2005 you get four listings of which the first is:
CVE-2005-1208Integer overflow in Microsoft Windows 98, 2000, XP SP2 and earlier, and Server 2003 SP1 and earlier allows remote attackers to execute arbitrary code via a crafted compiled Help (.CHM) file with a large size field that triggers a heap-based buffer overflow, as demonstrated using a "ms-its:" URL in Internet Explorer.
This shows up in the CERT list as Microsoft HTML Help Could Allow Remote Code Execution.
Notice the differences in terminology and emphasis: The CVE says "allows", CERT says "could allow"; the CVE lists four affected operating systems and includes their predecesor releases, CERT omits all mention of any Windows OSes, limits the impact to users of the MS HTML help facility, and elides the reality that this means virtually every IE user.
CERT links its headline back to its own June 14th 2005 bulletin. There, the problem is described as:
A remote code execution vulnerability has been reported in HTML Help that could allow a malicious user to take complete control of the affected system.[Affecting]
Windows 2000, XP, Server 2003 98, 98 (SE), and MECurrently we are not aware of any exploits for this vulnerability.
But the source CVE explicitly mentioned a demonstration attack.
Go back another step, to Microsoft's own bulletin on this and you get the "could allow" phraseology back along with the information that this is actually the fourth variant or update (see MS03-044, MS04-023, and MS05-001); that the vulnerabiity requires only that the user access an attack oriented website via IE; and that a much longer list of software is affected:
- Microsoft Windows 2000 Service Pack 3 and Microsoft Windows 2000 Service Pack 4
- Microsoft Windows XP Service Pack 1 and Microsoft Windows XP Service Pack 2
- Microsoft Windows XP 64-Bit Edition Service Pack 1 (Itanium)
- Microsoft Windows XP 64-Bit Edition Version 2003 (Itanium)
- Microsoft Windows XP Professional x64 Edition
- Microsoft Windows Server 2003 and Microsoft Windows Server 2003 Service Pack 1
- Microsoft Windows Server 2003 for Itanium-based Systems and Microsoft Windows Server 2003 with SP1 for Itanium-based Systems
- Microsoft Windows Server 2003 x64 Edition
- Microsoft Windows 98, Microsoft Windows 98 Second Edition (SE), and Microsoft Windows Millennium Edition (ME)
As a second example consider that CERT's complete list of Word vulnerabiilties for 2005 has only seven items starting with one headed: Microsoft Word Buffer Overflow or Arbitrary Code Execution
If you follow this up, you'll find that CERT refers you to a Microsoft Security Bulletin from July 12, 2005 replacing an earlier (and later) Bulletin that was revised four separate times:
V1.0 (April 12, 2005): Bulletin publishedV1.1 (April 14, 2005): Bulletin updated to reflect a revised Security Update Information section for the Word 2003 security update
V1.2 (May 4 2005): Bulletin updated to add msiexec in the administrative installation in Administrative Deployment section for all versions
V1.3 (May 18 2005): Bulletin updated Word 2000 file version for Winword.exe
V2.0 (August 9, 2005): Bulletin updated to reflect an additional affected product- Microsoft Word 2003 Viewer
Each revision added information as they discovered that the basic flaw affected, not just some generic Word release, but also:
Microsoft Word 2000
Microsoft Works Suite 2001
Microsoft Word 2002,
Microsoft Works Suite 2002,
Microsoft Works Suite 2003,
Microsoft Works Suite 2004
Microsoft Office Word 2003
Microsoft Word 2003 Viewer
In total, therefore, there are at least five updates, ultimately covering eight Microsoft Windows application products, affecting nine major OS variants - all counted as one in the CERT annual summary.
One final example: here's CERT's backup detail on a vulnerability listed as "Microsoft Windows SMB Buffer Overflow "
A buffer overflow vulnerability exists when handling Server Message Block (SMB) traffic, which could let a remote malicious user execute arbitrary code.[Affecting:]
Wndows 2000 SP3 & SP4, Windows XP 64-Bit Edition SP1 (Itanium), Windows XP 64-Bit Edition Version 2003 (Itanium), Windows Server 2003, Windows Server 2003 for Itanium-based Systems
Currently we are not aware of any exploits for this vulnerability.
Contrast that with what the underlying CVE (2005-0045) entry says:
The Server Message Block (SMB) implementation for Windows NT 4.0, 2000, XP, and Server 2003 does not properly validate certain SMB packets, which allows remote attackers to execute arbitrary code via Transaction responses containing (1) Trans or (2) Trans2 commands, aka the "Server Message Block Vulnerability," and as demonstrated using Trans2 FIND_FIRST2 responses with large file name length fields.
Notice that the CVE cites NT 4.0; mentions demonstration code, replaces a "could let" with "allows", and offers a more general view of the vulnerability.
I haven't reviewed very many of CERT's Windows listings, but this seems to be a general thing: with CERT's summary assessments of Microsoft related vulnerabilities being soft pedaled relative to the underlying CVE or Microsoft's own bulletins - and CERT's summaries showing fewer affected OS releases or products, fewer mentions of exploits or demonstration code, fewer mentions of previous patches that failed to completely fix the problem, and fewer mentions of patch or report updates.
As I said last week, CERT's excuse for its over reporting of claimed Unix vulnerabilities is that it merely counts claims and doesn't pretend to judge the validity of those claims. According to this argument, misleading news reports like this one by O'Reilly's Preston Gralla are the result of reportorial laziness or incompetence, and therefore not a predictable consequence of the way CERT selects and publishs its summary information.
"Windows Has Fewer Security Holes than Linux" (Jan. 11, 2006)The conventional wisdom holds that Windows is a security sieve, while Linux is locked down tight. Then why does Linux have three times the number of security holes as Windows?
A 2005 year-end vulnerability summary by US-CERT (United Stated Computer Emergency Readiness Team) concludes that Linux/Unix accounted for an eye-opening 2,328 vulnerabilities, about 45 percent of the total of 5,198 vulnerabilities for the year.
Windows, by way of contrast, had only 812 vulnerabilities during the year, 16 percent of the total.
...
I believe, however, that CERT's defense is Clintonesque in its evasiveness, and that Mr. Gralla should feel embarrassed by his source rather his actions -he did nothing wrong in correctly reporting what CERT said and, in fact, added a warning a bit later in his article that not all vulnerabiities should be considered equal.
Nevertheless CERT's "Caveat Emptor" argument might have formed the basis for a workable defence if CERT had applied the same approach to both sides of the list. But that's not what they did: instead, any they seem to have uncritically accepted almost any vulnerability claim that could be counted against Unix while sanitizing and "down threating" at least some Windows vulnerabilities, failing to count at least some updates expanding the scope of the vulnerablity, and silently dropping at least some mentions of exploit or demonstration code.
The bottom line is simple: this looks like systematic anti-Unix, pro-Microsoft, bias at work in a U.S. federal government agency charged with honestly informing the public about OS and related cyber security risks -a job they're not doing.