.:Computer Defense:.

... and for his first trick, Ladies and Gentlemen, he will make Windows Server 2003 SP2 appear magically in front of you... as though out of thin air.

Ryan has already blogged about this over at numerophobe.com but I think there's information worth mentioning again and other information that's worth bringing up. This was definitely a quite little release... not nearly as loud as previous service pack releases from Microsoft have been, and the regress issue that Ryan talks about is quite interesting...

I thought I'd provide a couple of links that are worth reading:

• What's new in SP2
• Top 10 Reasons to Install Windows Server 2003 SP2
• List of Updates in Windows Server 2003 SP2
• Security Bulletins Included in Windows Server 2003 SP2 (Microsoft Claims this is Vulnerabilities Fixed in SP2, more information below on that)
• Windows Server 2003 SP2 Data Sheet
• Windows Server 2003 SP2 Release Notes

Now the Security Bulletins list is interesting... Microsoft provides a list of these bulletins, however on the SP2 main page they refer to the list as "List of Security Updates in SP2". Here's my problem with that... ISC has released a list of CVEs that are supposedly fixed in SP2, there are several listed without related MS Advisory numbers... yet according to Microsoft every one of their security updates in SP2 was covered, at some point, by an MS Advisory. This is contradictory information. Microsoft actually provided an explanation for one of these issues back when it was first reported... they didn't feel it was important enough to warrant it's own patch. Yet they still don't consider it a security update in this service pack, even though they apparently fixed it.

And now.... The second trick.

Perhaps Microsoft feels that by limiting the assigned MS Advisory Numbers, they can limit the number of vulnerabilities that affect their platforms. If that's the case we have an explanation for the Windows XP Patch that was released quietly on Patch Tuesday... sans MS Advisory Number and therefore not a patch. The patch is related to a race condition in the memory manager. Now perhaps a race condition isn't all to serious, perhaps it causes a DoS when it occurs, but that's still a vulnerability and in this case it's a vulnerability that causes a blue screen. In the old days ("ping of death") a blue screen was a serious issue... now it seems that Microsoft is ignoring them as being vulnerabilities. Perhaps Microsoft and OpenBSD got together and discussed what is and is not a vulnerability. I guess Microsoft has made it clear via their conversations with ISC (relayed via the 'Missing Microsoft Patches' list) that they don't consider a Denial of Service worth patching these days. Is this a cost cutting measure on their part or just pure laziness? In either case I wonder how long until privilege escalation is no longer worth covering and then... maybe we won't even need to cover remote code execute. Regardless failure to provide patches for public issues is irresponsible and disgust with this process should be expressed by the public.

Perhaps an interesting concept would be IT Watchdogs... more organized than anything currently out there. There are plenty of government watchdogs. So why not legislation that creates an IT Watchdog... Computers are an integral part of life and we can no longer afford these magic acts. We need real action... not deceptions and "misnaming to save from diluting the meaning of the word". A government legislated watchdog... or perhaps a private watchdog (but then who's to give them any power or control) would be great.... paid for by tax payers dollars (I know... that'd never fly). The watchdog would be comprised of IT/IS professionals and be tasked with keeping track of all vulnerabilities (including those that vendors feel dilutes the meaning) that are reported to a vendor or published publicly. The watchdog would also be tasked with ensuring that certain time lines are maintained... no more of this 150 days to patch garbage. A consortium of vendors and professionals could decide on the requirements (patches within 30 days, 60 days or 120 days for example)... or varying time lines... 30 days for remote code execute, 120 days for DoS. They would also as a group determine fines or levies that a vendor would pay should they not meet the required deadlines... $10,000/missed patch for example... perhaps a sliding scale here dependent on the revenue of the vendor and the levy rate... per day accruals or per month accruals for example...

It's time we stop dealing with magic and leave that to children's birthday parties with black hats and white rabbits. We need to deal with the truth.