Alan Shimel blogged today about rapid versus responsible disclosure of vulnerabilities by third parties. I agree whole-heartedly with Alan that we need responsible disclosure, by the vendor whenever possible, of vulnerabilities.

Rapid disclosure serves the bad guys the following ways:

1. It gets the word out about the vulnerability and often the technical details of said vulnerability as well as proof of concept (POC) code, which is often used as the basis of a worm. The Blaster worm was a case in point; POC came out and opened a listening shell on port 4444. Fifteen days after POC, a worm is discovered that opens a listening port on none other than port 4444. That tells me the author of Blaster probably didn’t have the skills to discover the vulnerability on his own but he was able to mash the POC into an effective worm. Therefore in the case of Blaster, it is highly likely that without rapid disclosure we wouldn’t have had the worm.
2. Prudence dictates that the security team keep the IT team up to speed on the status of their security posture. When there is a vulnerability with an associated exploit, you have increased risk. Unfortunately, after several communications from the security team regarding vulnerabilities they can do nothing about, the IT folks could become desensitized to the communications. “Oh, this is probably another vulnerability I can do nothing about, so why even read the email.”
3. The bad guys get a jump on the race between public disclosure and patch release. Normally, if a vendor is allowed to publicly disclose along with a patch release, all parties start from the same point. However, if public disclosure happens before patch release, the bad guys are off and running and the good guys are likely left waiting for the patch before the have protection. (another argument for implementing defense-in-depth so you aren’t entirely dependent on patches for security)

Rapid disclosure serves the average good guy the following ways:

1. They know what hit them.

Alan touched on third party patches in his post and again I agree with him that they are like playing Russian roulette but I disagree they will pressure vendors into releasing a patch too soon, at least not Microsoft.

Back in April I wrote a series of posts about third party patches. I was irked after the WMF and the IE createtextrange() vulnerabilities were disclosed rapidly and weeks before Microsoft’s asinine, rigid monthly patch cycle. I won’t revisit the series here, you can read it seperately if you are curious but in neither case did Microsoft deem it necessary to release an out of cycle patch. As an aside, in article three of the series I was again commenting on one of Alan’s articles. I know it looks like I’m a Shimmy fanatic, which may or may not be true, I’ll never tell. However, he does get me thinking, which is a good thing.

What’s the fix? Lets say I discovered another vulnerability in IE and notified Microsoft about it 30 days ago and no patch has been forth coming. I need to let the public know about it and I need to put the heat on Microsoft to do the right thing but I don’t want to be responsible for ATM’s in Muskogee spitting cash into the streets because some script kiddie wrote a worm from my POC. What to I do? I notify the IPS/IDS and AV vendors one week before I go public and I provide them the POC before I publish it. That shows the world I have the best intentions.

We as a security community not only have to pressure Microsoft to ‘do the right thing,’ we also have to beat ‘defense in depth’ into the head of every IT person on the planet. If a corporation is depending solely on patch management for security they’ll forever be at the whim of Microsoft and won’t have control over the security of their network.

For more information about this topic

• No Related Post