Slashdot Mirror
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."
No it's not a bad thing.
Go read up one of the gazillion explanations of "full disclosure".
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?
If we can hit that bull's-eye, the rest of the dominoes will fall like a house of cards... Checkmate.
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.
Well, it's one thing if Microsoft says "this is an update", as opposed to "this eliminates a security flaw". I don't think Cisco was explicitly stating that patches were for security, and I don't think Microsoft could be expected to be responsible if it issues a patch labeled as a security fix and a user doesn't apply it.
The problem arises when Microsoft decides that an 'undocumented' capability is the source of a bug. They fix the hole, but this may break your software in unpredictable ways. If you don't know what they fixed, you have no idea what (or if) things will be broken by the fix.
Remember -- for some people, Windows is used for much more than just games. If a patch breaks a mission critical piece of software it could cost some companies hundreds of thousands of dollars an hour.
Then, of course, there's just the people who want to count how many dozen MS security holes there were this week.
Free Software: Like love, it grows best when given away.
This site mentions a high-level I/O-processing bug that was present in csrss.exe in many versions of NT/2K/XP that could be triggered by something as simple as a opening a text file that contains a bunch of backspace characters.
"On 2002-09-24, Microsoft KnowledgeBase article ID Q311486, promised six months ago, finally appeared. Its publication date is falsified to claim that it appeared on 2001-10-26. It talks about programs that "pass invalid screen size parameters" when the sample program code that it gives for replicating the bug clearly contains nothing at all relating to screen size parameters."
This would NOT happen in the Open Source world just because of the transparency of the software. OSS could not include such devious actions without a million people seeing it before it even gets to your machines. I frequently check my updates even before I update my servers/desktops. I know what is getting put into my Linux boxen.... Do you???
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.
"In spite of everything, I still believe that people are really good at heart." - Anne Frank
No, the crux of his complaint is that he can't tell what he's supposed to be looking for. How is he supposed to test what M$ does not tell him? For some reason he thinks M$ is going to tell him what their "updates" do. How many hours do you expect him to test every month?
It's incredibly stupid to put yourself out on the line like that. One day it'll come back and bite him when he's wrong.
Looks like you've already bitten him. Do you work for M$ or do you just like shooting your mouth off?
The only dumb thing here is trust in M$. Look at the reward he's getting for all of his "responsible disclosure" and patient work trying to patch the XP sieve. He sits and waits for 700 days while everyone else gets hosed. M$ is oh so happy he's put their interests ahead of yours. Yet, you've acted like Steve Baller and called him incredibly stupid now that he's changed his mind and stood up for you. Other's have called him selfish and publicity seeking. I think he's getting a little fed up with it all, which is the first step in a very smart move.
Friends don't help friends install M$ junk.
>> I fail to see any law or EULA where such notifications are required.
There are things you do because of the law and then there are things you do because they're right. The issue at stake is the how much you trust MS to not break things with their fixes. What happens if a fix causes a critical application to break?
Say this was at a paitent records system in a hospital? Say they changed their image handling code and xrays could not be displayed because the fix broke something either in operating system or in the application because the vulnerability might have accidentally let a bug go through the QA processes. Now imagine if the fix was deployed saying that it addressed an obscure issue with Outlook Express. Administrators and software developers could end up wasting a lot of critical time.
Imagine a scenario where Pzifer changed the formula of Viagra without informing the FDA or the physicians involved in dispensing them... imagine if that side effect.. oh never mind, you know where I'm going with this.