Microsoft's Security Disclosures Come Under Fire

Old Banana writes "Is Microsoft silently fixing security vulnerabilities and deliberately obfuscating details about patches in its monthly security bulletins? Matthew Murphy, a security researcher who has worked closely with the MSRC (Microsoft Security Response Center) in the past, is accusing the software maker of 'misleading' customers by not clearly spelling out exactly what is being patched in the MS06-015 bulletin released on April 11."

Comments

Patches

[dotslashdot]

How would you like a birth control patch that also doubles as a nicotine patch without your knowledge? Sure you can have sex without worrying about getting pregnant, but there would be no cigarette afterwards. What MS has done is taken away the cigarette from the consumer. My Windows sex machine can "interface" all night long without getting pregnant, but it can still get STDs and won't be smoking any more afterwards.

Re:Patches

[WilliamSChips]

And I thought car analogies were bad...

For "users" it is fine... For biz - no.

[NotQuiteReal]

For most folks, hey, it's all mumbo jumbo anyhow. Closed source, closed patches. "It's an update, Trust us, you want it." - OK, Click.

For Business users, they might actually want to know what might break if they do the update - especially since many cannot be "un-done".

Yes

[WebHostingGuy]

This brings up the age old debate which I will not revive. However, my spin is that if you are patching a vulnerability you should disclose that. Otherwise the end user might not apply the patch. This very same situation happened with Cisco at Blackhat and ended up in the Courts and Cisco ended up with a public black-eye. Based upon the IT reaction to that I would venture the assumption that we want to know.

Security by obscurity at its best

[hweimer]

If you explain exactly what is being patched, then you give the hackers a pretty clear roadmap of what they need to do to exploit all of the unpatched systems, don't you?

You do that already by providing a patch. The bad guys will simply look at the differences of the binaries and find out what has been patched. So instead of helping the good guys, Microsoft gives an information advantage to the bad guys.

Hidden DRM?

[Clazzy]

Remember when there was an update to Windows Media Player that added those DRM module things and there was a big outcry? I may be acting a bit paranoid, but isn't it remotely possible that Microsoft could sneak in other restrictions like this without users ever knowing?

Here is the problem

[IntelliAdmin]

The big problem when they do this is compatibility testing. I work at numerous companies where we need to read through each patch to see what they 'fix'. Now when Microsoft does this we will just have to guess what they might break in a legacy application deployed across the world.

Re:Corporate responsibility?

[walt-sjc]

I would think that corporate "Software Assurance" customers who are paying for continual updates and support, and have to support MANY legacy applications that may be affected by such flaws or patches would be (and ARE) demanding such notifications. Joe Bob Home User does't really care, but Fortune 100 Fred in IT sure does, especially when his job (which is to keep the companies infrastructure up and running) is on the line.

Microsoft patching without consent? Maybe

[NullProg]

How to find out? MD5 sum your /windows folder including the sub-directories (don't forget the hidden ones) before the patch. MD5 Sum again after the patch and compare the results. bdiff the questionable file differences and dis-assemble. At least thats what I used to do as a prior legitimate Windows license(s) owner (but before being called a thief by Microsoft).

Like I said earlier today, you either own a Microsoft appliance or a personal computer, these days you can't have both. Switch to something else or stay with Windows.

Enjoy,

Remember, boys and girls.

[khasim]

The bad guys don't need to spend time with compatibility or regression testing for their software.

They can download the patch the day it is released and have an exploit ready that same day. You'll still be meeting to discuss the test plan for your servers.

Attempting to hide information doesn't help anyone except the vendor and the bad guys.

At least if you have the information, you can determine your own level of exposure and decide what mitigating actions you want to take based upon your environment.

KB908531 Broke Word 2002

[ktakki]

Yesterday, my office gets a frantic call from one of our clients, a lawyer. She had a filing deadline and was trying to finish a document she needed for this filing. Word 2002 stopped responding to user input every time she tried to save her document. All of my techs were out in the field, so I had to respond to this one (I'm VP Operations).

True enough, saving a document in Word or trying to open a new one while another document was open would hourglass the cursor. Only Task Mangler could end WINWORD.EXE.

Sysinternals's PROCEXP showed that every time a document was saved, Word would spawn VERCLSID.EXE as a child process, an executable that was "patched" by KB908531, which was pushed through Windows...err, Microsoft Update the day before.

I googled "verclsid". Let me tell you that yesterday, this search string returned no results. This morning, it returned exactly one. Now, it comes up with 67 web hits and 21 Usenet results.

Also, because of this "patch", typing "www.google.com" would return the generic IE "Server Not Found" page. One had to prepend "http://" to the URL. VERCLSID.EXE checks the validity of COM objects, so the damage wasn't confined to Office applications; it affected EXPLORER.EXE and IEXPLORE.EXE.

The workaround was to rename the current version of VERCLSID.EXE and restore the file from the backup created by KB908531 (a System Restore would have sufficed as well). I expect a patch for the patch to be released by Microsoft Real Soon Now. I guess this one was rushed out the door without sufficient testing.

Our company policy for patches is this: updates for servers are tested in-house before being deployed on production machines. For workstations, however, Windows Update is set to automatically update, unless the client's workstations run legacy applications, like the Reflection terminal emulator, or if high-end esoteric applications are present, like DataCAD or Design 20-20. As with servers, they're tested on a non-production system first.

I'd say that 10% of our clients got burned by 908531. Rolling it back wasn't that hard once we identified the problem, but this costs money.

I don't want to single out MSFT; last year an Apple Mac OS X security update broke Samba for me for about a week until I could figure out a workaround. But let's put this in perspective: how many people using Mac OS X (2 to 5% of the workstation market) also use Samba? Contrast this with the percentage of Windows XP/2K users also using Word (must be in the high 80% range), Internet Explorer, and the GUI, all affected by a buggy 908531 patch.

k.