Watch this quick Whiteboard Wednesday video to learn all about different vulnerability disclosure tactics. Learn the differences between responsible, full, and reasonable disclosure and see why people use these different tactics. This video is presented by our Metasploit Framework who also talks about how Metasploit approaches vulnerability disclosure.
Read Video Transcript
Hi. I'm Todd, and I work on Metasploit; I am the engineering manager at Metasploit on the Metasploit framework. I live in open source land, I live on the internet, which means every once in awhile I get to deal with this, disclosure of bugs. Security bugs are special in that they enable people to use programs and systems in ways that they weren't necessarily intended to be used. Over the years on the internet, we have fallen into 3, technically 4, methods of disclosing vulnerabilities. I'm going to go over them, and I'm going to talk about what we do here at Rapid7 with Metasploit, and that is Reasonable Disclosure.
A little history: What most people are familiar with right now is Responsible Disclosure, and that's 'responsible'. This represents bad old days of disclosures, where you as a researcher find a security bug, you report it to a vendor, you and the vendor supposedly work with each other and get a fix out. This can take anywhere from a couple days, if it is a very responsible vendor, to a couple years if it's a non-responsible vendor. The problem with this is that it encourages the bad old days of secret bugs. Everybody has their own piles of secret bugs, and this is one step away, really, from the whole no disclosure thing, which is great if you want to capitalize on bugs and commit crime, not so great if you are a nice internet citizen.
With 'Responsible' Disclosure, the vendors are really like this, it gives vendors lots and lots and lots, infinite effectively, time to fix bugs and everyone has to wait around for a vendor patch, usually everyone being the users, and anyone affected by this stuff. On the other extreme we have Full Disclosure. This cropped up a few years ago as a response to the vendors basically not operating on Responsible Disclosure. It wasn't called that at the time, it was just called Disclosure. Full Disclosure was a response to that. With Full Disclosure, everybody knows about the security issue all at once, and by everybody that's anybody who pays attention to any security mailing list, usually people who pay attention to people who pay attention to security lists. It gets out really fast, usually with no notice, and the vendor and the bad guys are dealing with this bug at the same time. The bad guys obviously want to come up with an exploit, oftentimes there's an exploit attached, the vendors either raced against time, race against the bad guys, or do nothing for a little while and issue press releases. It's just a big ball of stupid. This is not something that we want to encourage, but if someone does Full Disclosure we're happy to a Metasploit module. That's part of the deal, is that when there's Full Disclosure being practiced, anybody can write exploits for it, including us. When there's no notice, obviously, this is a chaos situation, and this is not a very friendly thing to do.
What we try to practice here, what we do practice here at Rapid7, is this notion of Reasonable Disclosure, which like in most things, it's a middle path, it's very Zen. If we happen to find bugs in products, and we have in the past, we notify the vendor, 15 days later we notify CERT because they're really good at disclosure, and then 45 days after that, we release information about the bug, and usually, nearly always a Metasploit module to go along with it so you can test. What this sets up is a very limited timescale, it's a little bit negotiable, but not to the level that you see in Number 1, we are not waiting around years, because mainly, we know that while we're smart, the internet is full of really smart people who probably have found this bug before anyway. They may be actively using it.
An example of why this seems to work and is that we will tend to notify vendors, they tend to be responsive, they tend to get a patch out really fast because they know we are serious about releasing, and we have the chops to actually exploit it, and then everyone wins. What you end up with this are open source exploits that can be used to test the efficacy of the patch. This is great for everyone, and there is no room for debate, at all. I challenge you to debate on pros and cons of all of these disclosures. By the way, I said at the beginning there are technically 4, because then the fourth is, of course, no disclosure at all; you hoard your bugs or you sell your bugs, and whoever you sell it to will do one of 4 disclosure method after that, and then you get paid, which is nice, I guess, for you, not so nice for the internet. We like knowing about lots of vulnerabilities because we like writing Metasploit modules, it's totally fun, but we like to do it in a way that seems at least reasonable or the continued usefulness of the internet.