The Story of a Microsoft Patch

buckethead writes "eWeek is running a story about a security patch from Microsoft that failed to adequately address a denial-of-service flaw on CSRSS (Client/Server Runtime Server Subsystem), the user-mode part of the Win32 subsystem. It stems from a research paper from Argeniss that discusses how Microsoft only patched one path to the vulnerable function, but they forgot to do proper research to identify all the paths." From the article: "The problem was that Microsoft didn't patch the vulnerable function; they just added some validation code before the call to the vulnerable function, but what Microsoft missed was that the vulnerable function can be reached from different paths and the validation code was added on just one of them"

Comments

Why didn't tehy fix it right in the first place?

[Barkley44]

Why didn't they fix the vulnerable function in the first place (is there a specific reason)? Sure, adding validation seems like a quick and valid fix, but a company the size of MS should have known in the long run, fix the function instead.

Is this really that bad?

[ebob9]

The article criticizes Microsoft for not fully understanding the vulnerability, and issuing an incomplete patch.

I understand that in a best case scenario, a vendor should release a 100% effective patch. However, in reality, that's not always going to be the case.

Microsoft released a patch that stopped the public vulnerable attack vector. Then, once they were alerted that they didn't fix all possible vectors, they issued a new patch (albeit quite a few months later).

With the large amount of bugs and vulnerabilities that a software behemoth like Windows is going to have, is it really that unthinkable that an incomplete first-patch would be released? I'd wager that even OSS products routinely have incomplete first-patches.

Re:Is this really that bad?

[QuietLagoon]

Yes, this is really that bad. Software development is supposed to be Microsoft's core competency. That they are not knowledgeable enough to patch the root cause instead of the symptom speaks volumes of their incompetence in their supposed core competence.

The first question I'd now ask is what other symptoms have been patched which have left other vulnerabilities open for exploit via other attack vectors?

Re:Is this really that bad?

[Metroid72]

Just to be clear from the begining: I don't disagree with you.
Your underlying assumption is that Microsoft's core competency is software development, however, I think that's debatable. Over the years they've demostrated that they are a better Marketing company than a software development company.

They happen to be very fast to identify consumer needs or technology trends (either by researching or copying others) and integrate them quickly in their product portfolio. I think that aggresive way to integrate new features tends to help a lot in writing bad code.

It's not until lately, due to the size of the company and layers of bureocracy that MS is having a tough time releasing products and features to market quick enough. Since the birth of the internet they have been very reactive, but now it's taking them longer to react to the market realities and trends.

Re:Is this really that bad?

[SharpFang]

It's okay to release a "quick and dirty fix" immediately. Like Firefox, disabling whole feature that is vulnerable. But they shouldn't need to be told the fix isn't good. They should start working on a full, proper patch as soon as the hotfix is ready, and be aware WHAT the vulnerablity is. Put a band-aid on the bleeding wound right after the accident, okay, but then let the surgeon remove splinters and sew the skin together properly once the patient arrives at the hospital. Don't leave as-is because it's not bleeding at the moment.

Security and the stock price

[ewg]

Has any Windows security problem ever hurt Microsoft's stock price?

I checked MSFT a couple of times when mail-based malware was running amok, seriously enough to reach the general news media. No effect.

If that's the overall pattern when it comes to Microsoft security issues and Microsoft's business success, it goes a long way toward explaining security missteps like MS05-018. There's no direct incentive for them to master security.

Re:Great...

[Taladar]

The proper process actually is not to write tightly coupled modules bigger than the size one person can know completely. It is well known by now that software development is too complicated if you write several million line programs without dividing them in a way that makes them more similar to a large number of small, separate programs.

Re:Why didn't tehy fix it right in the first place

[The Lerneaen Hydra]

Maybe because they didn't really care about the other ways to get in, but all they cared about in this case was their image to the outer world, and thereby being able to say "See, look at us, we patch our flaws immediately".

Re:Symptoms vs Causes

[bcmm]

Well, is that wrong? Isn't that exactly what they did in this case?

Hey, its Micorosoft. This is what they do...

[sjanes71]

They have lots of practice at it. Practice at what? They disclaim or disable the user to death. Instead of fixing the holes, they pop a dialog window and confuse the user. "Hey, some program is accessing your address book!" "You're about to enable file or printer sharing, are you sure that you want to do that? Someoone might, uh... get some files or use your printer over the network." "You're not allowed to open attachments until you find this one little checkbox and click it before we let you open attachments, because we think you're stupid." Everyone of these little dialogs is a tiny micro-EULA that users never quite read or understand.

This happens over and over and over again— with some users, I'm afraid to upgrade their software because their "world" sadly depends on the cargo cult execution of gestures to get their work done. Too many applications change how they look and feel with every upgrade that many users go off the rails whenever that happens. At least with an application, you can kind of avoid it, but when it's Windows— aw man, why not just fix the SECURITY HOLES instead of changing the UI? Please, Microsoft?

Screw it [sic; I'm being polite.], I'll keep my Mac OS X for clients and Gentoo Linux for servers and any web service that doesn't suck (Gmail, Basecamp, etc.), thank you very much.

Microsoft's days are over the moment Google decides to market an operating system that includes GFS for redundant data-storage and their MapReduce for batch processing. These things are big contributors to how its even possible for Google to exist. Simplicity trumps mediocrity.

Re:Why didn't tehy fix it right in the first place

[dlasley]

One must also consider the possibility that the folks doing the coding and the quality assurance (SQA) may not be the original authors of the specific branch involved, and therefore did not have the proper experience level required to do the research and make the judgement calls. With the rumored turnover Microsoft has seen lately, I wonder if this is not a possibility?

More and more of the post-development activities (break/fix, SQA, implementation/packaging, etc.) for software are happening in little bubbles, somewhat removed from the core competency group that created the original code. We even see this touted as the right way to do things from sources that are considered to experts in the process + workflow arena (well, some folks consider them experts, anyway). When this becomes the standard operating procedure, any company runs the risk of bad patches to any kind of software: you can not limit the culpability to Microsoft.

Re:Why didn't tehy fix it right in the first place

[deaddrunk]

Probably goes like this:

Coder(s): this will take two weeks to fix and test properly

Management: you've got four hours.

Remember This Story

[bfree]

The next time MS claims it fixes security holes faster then anyone else ...