Posted on Saturday, April 8th, 2006 | Bookmark on del.icio.us

The Market-Driven (Vulnerability) Economy, Part Deux

by Mark Zielinski

Jose’s post on buying and selling vulnerabilities got me to really start thinking again about whether vendors should pay independent security researchers for the information they discover, and, if they choose not to, have a say in applying stipulations to that research, such as rules of disclosure or anything else. Personally, I don’t believe that I should have to hand over any of my research or agree to any stipulations they have, and it’s an insult for the vendor to ask anyone to do so. That vulnerability is the product of a lot of hard work and time which went into it’s discovery and development, and it has a lot of value. If not to the vendor, than most certainly to somebody else, no? That value is dependent on many different factors. For instance: how many product versions does the vulnerability affect? Is it local or remote? Is somebody else already offering money? How much would it be worth to a company that develops vulnerability scanners to have zero-day vulnerabilities? What about their competitors? How about to the government or international entities? These don’t come even close to covering all of the potential scenarios.

You could say that vulnerability research amounts to quality assurance in some ways, and I’d agree with you. In other ways, it’s also intellectual property. Let’s try an analogy. There are many organizations who may need to do their own research on a particular product….say Microsoft Windows. Maybe the organization is trying to gain a competitive advantage over one of their other competitors. Whatever the case may be, a lot of hard work goes into that research for the organization’s benefit. When the organization has finished its research, does Microsoft have an expectation that the company will just hand it over to them for free, just because it involves one of their own products? Obviously not.

I’m constantly amazed by how simple these answers are and yet some vendors simply don’t get it. The world is changing, and I think it’s time that certain vendors wake up and take a look around at the new world they live in.

This entry was posted on Saturday, April 8th, 2006 at 4:46 am and is filed under Events, Exploit Code, Vulnerabilities. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 Responses | Add your own



Comment Post by: Tom Ptacek — April 9th, 2006 @ 3:15 pm EST  Reply

Mark, you’ve been doing this since 1997. Did Id Software impose stipulations on you? Sun? BSDI? (They accused us of ruining Christmas, but guilt isn’t a stipulation).

The elephant in the room is patching. If you use the word “own,” then you “own” the finding and the responsibility for what you do with it. Which includes the whirlwind, if you publish without making sure a viable patch is available.

I’ve worked for ten years under a variety of conditions including NDA, no-reversing licenses, and two threatened lawsuits. I’ve lost more time to copy-editing advisories than I have to the combined impact of all that vendor static. On the other hand, I am now, as I was five years ago, behind the 8-ball on vendor patch scheduling. And, there’s really nothing I can do about it: you can’t force a vendor to patch anything.

So, since you’ve been doing this for awhile, I’d like to see you say something more than, “I don’t like it when vendors are presumptuous.” Do you have an answer, a proposal, or a novel insight about the patch problem? Do you see vulnerability markets addressing the problem? I don’t: I see vulnerability markets as a way to monetize the “float” of time between discovery and publication, and thus as an incentive to delay publication — and thus a bad thing for everyone.

What I’m really waiting for is for someone to clearly articulate the value in learning about a vulnerability, say, two months before the rest of the world. We intuit that the value is there, but, what is it?

Comment Post by: Mark Zielinski — April 18th, 2006 @ 11:24 am EST  Reply

Thanks for the comment, Tom. While working at Repent Security, I did encounter some vendor resistance and they did try to impose stipulations on us. This is just one problem of many, but for instance, Sun Microsystems would routinely ask us to wait for two or three months before we could release any information. If we didn’t, they claimed they wouldn’t give us any credit for finding and reporting the vulnerabilities. There was even one instance where they had asked us to wait for up to 12 months. I know there were others who had encountered these same problems with other vendors in the past, and it was getting a little out of hand. Besides completely re-writing a complicated application or protocol which is deeply integrated into the OS, there really aren’t any good reasons why patching a vulnerability would take 12 months, IMO.

I think these problems can be addressed in various ways, but what it all really comes down to is vendor responsibility. First, if vendors had been more responsible and had taken security more seriously initially, then we probably wouldn’t have as big of a problem as we do now. Second, many innovative solutions currently being developed can address many of the problems we see today. For instance, many private organizations have been developing technologies capable of preventing vulnerability exploitation before they are discovered. Why aren’t vendors doing this? Every OS today should have technology like this that is deeply integrated within the core. At that point, who cares if a patch is taking a little bit longer to release? In most cases, customers are already protected, right?

I want to point out that Microsoft is already addressing problems like this. For some reason, they’re always put down, but in reality, I think they are one of the few vendors who take security very seriously. In my opinion, other vendors should be watching them very closely as they are starting to do what everybody else should be doing. They are either buying or developing technology that can address problems like this by preventing vulnerability exploitation, well before it becomes a public problem, rather than simply waiting around to patch the next publicly discovered vulnerability.

Leave a Comment