One of the last things I did before I left on vacation was to help arrange for the release of a research tech report on the Strider Honeymonkey research project.
I just listened to this podcast report from Steve Gibson and Leo Laporte on the topic. It gets a lot of the facts right, but requires a few clarifications and retorts.
First, they try to make hay of Microsoft trying to be protective of the information as some sort of unfair competitive advantage. That's complete garbage. WE PUBLISHED A TECH REPORT. We told everyone exactly what we did, and guess what? Everyone else could do it too. Gibson says so himself: there's nothing particularly hard about doing this, and it could easily be replicated. That's the most important information that we could release. But to the question: why are we not releasing the list of URL's? Because HoneyMonkey is a lead generation tool; it tells us when one of the HoneyMonkey machines gets modified, but not how or why. We have an enormous amount of investigation to do before we know the how and why, and we want to make super sure that we're doing this right and not releasing bad or useless information. So we (MSR) work closely with our security teams to do that investigation and take appropriate action once we have conclusive infromation, including involving law enforcement agencies if appropriate. It takes a while, but once again, we want to make sure we're doing this right.
Second, the HoneyMonkey system gets seeded with a lot of sites beyond just IP addresses harvested from lists of known bad sites. But even then, it crawls from its initial sites out to all the linked ones.
Third, they play loose with the definition of "zero-day exploits" to make it sound like Microsoft was doing something bad. The Honeymonkey system did in fact find a zero-day exploit back in June. It was for a vulnerability which had been disclosed at the time and for which there was much discussion and advisories for how to mitigate it, but for which there was not yet an update that fixed the vulnerability. Gibson and Laporte make it sound like Microsoft knew of a vulerability but was hiding that information because of some evil plan, which is absolutely NOT TRUE. We do advocate for responsible disclosure, meaning that essentially it isn't a good idea to yell "Fire!" in a crowded theater; disclosure should happen when there's an appropriate response to be taken, otherwise you're just causing panic and also tipping off the bad guys as to how to wreak even more havoc. In an ideal world, there would be near-instantaneous turnaround from a vulnerability reported to Microsoft (or any other vendor) to having a patch available; in the real world, it takes time to understand the vulnerability and potential exploits, design an appropriate fix, build it, test it, document it, and distribute it. In the podcast, Laporte makes an offhand comment about how Microsoft might know about serious security vulnerabilites but decided to fix it "when we get around to it" and just keep it quiet. That is absolutely untrue -- I can assure you that all security vulnerabilities are taken quite seriously and are not simply shoved under the carpet in the hopes that no one will discover them. The problem is that sometimes the fixes are not obvious or trivial, and might break important features that our customers have come to depend upon in another context. In those cases, we have to go talk to our customers, understand the real-world usage patterns, and figure out workarounds so that we can close the security hole without breaking our customers' installations. This is all horrendously complicated. The lesson here: silence from a vendor doesn't imply that the vendor is ignoring the problem; sometimes doing and saying the right thing takes time.
Overall, I was pretty impressed with the thoroughness of Gibson's analysis and reporting. He clearly read the information through and understood it deeply. And like everyone else, he and Leo got a kick out of the name.
10:16:08 PM 
|
|
