5 ms·

I strongly disagree, and don't follow this logic. Responsible disclosure is intended to be ethical, the opposite is ... well, irresponsible. I've worked with

I strongly disagree, and don't follow this logic. Responsible disclosure is intended to be ethical, the opposite is ... well, irresponsible. I've worked with irresponsible security disclosurists before, and even those that agree to a window only to dump another small variation after the window is up - rather than working to make sure the product is as good as it could be. Giving end users time to patch so they are not owned is quite a ethical thing to do. The end goal is less compromised systems. Doing this at the same time achieves the opposite effect and increases the amount of compromised systems. It's never been "we're giving you two weeks, get it done fast because the exploit is going out then", it should be "we'll give you enough time to fix this properly, and then give the customers time to update once announced". I personally would always release when something got done early, just because the person on the other end is usually unpredictable. However, the person on the other end shouldn't assume development of the fix didn't take the full interval. Let people pen-test after they had a chance to update to secure the systems. Having the ability to prove a fix is not worth systems being owned prior to being able to fix them. The damage is already done at that point. I've worked a lot of CVE reports, and about half the time, the person on the other end just wants credit, they aren't really going to hang around and try to help, and often they supply terse information (i.e. no exploit PoC to the vendor) as some form of game. I'd much rather this always be more user focused, the ultimate desire should always be to help the end user, and often users are less educated and don't have dedicated security teams.

wcummings 11y ago
An exploit as the fruit of someone's labor is non-trivial, often holding significant monetary value. They (exploit authors) have no obligation to release it to the vendor at all, let alone for free and "responsibly". Is the unpaid labor scheme you're describing "ethical"? If vendors want "responsible disclosure", they can simply buy exploits at market value.
- CHY872 11y ago
  Sounds great, but doesn't really work with open source software (unless I have some wires crossed). Who is supposed to pay for an exploit in (say) MariaDb? The value to a sufficiently motivated black-hat organisation is surely far higher than the value to any one user of MariaDb, no matter how big they are.
davidgerard 11y ago
>Responsible disclosure is intended to be ethical, the opposite is ... well, irresponsible. It turns out the name was chosen for its connotations, i.e. to sound good. If you call it "coordinated disclosure" it doesn't come into the discussion cheating.
- mpdehaan2 11y ago
  The points stand on their own, and I think it's useful to have a phrase that markets the practice. I personally view it as irresponsible regardless of whether we called it "Foo Disclosure". I do view sharing the exploit on the patch date irresponsible irrespective of the term. I believe the name was chosen well, and I don't think it deserves painting with "PATRIOT ACT" type brush. I've dealt with commercial firms as well as non-commercial firm disclosures, and really working with people who report security issues could go a LOT smoother. A lot of those experiences did not go well, but it would be wrong for me to make generalizations. Business here on either side doesn't matter; the user is all that matters, and it shouldn't be about getting "credit", earning points, or being done with something quickly. I think a lot of people think this is a game or something, and it's really not. Real systems and real people's data are on the line.
tptacek 11y ago
"Responsible disclosure" is a term of art coined by a group of vendors and consultants with close ties to vendors. Baked into the term is the assumption that vendors have some kind of proprietary claim on research done by unrelated third parties --- that, having done work of their own volition and at their own expense, vuln researchers have an obligation to share it with vendors. Many researchers do share and coordinate, as a courtesy to the whole community. But the idea that they're obliged to is a little disquieting. If vendors want to ensure that they get some control over the release schedules on their flaws, they can do what Google does and pay a shitload of money to build internal teams that can outcompete commercial research teams. Large companies that haven't come close to doing that shouldn't get to throw terms like "responsible disclosure" around too freely.
- CHY872 11y ago
  Although I take your point of principle, I'm not really sure I see any incentive to not share vulns. From what I can think, the options are: 1) Actively exploit - I think we can agree that providing it to someone who will actively exploit is ethically dubious, or at least can be classified as irresponsible? 2) Share with the vendor. Ethically, this is fine. 3) Do nothing with it. Ethically, this is fine, although pointless. 4) If you make software that's supposed to detect and/or block the use of such vulnerabilities, add it to the detection system. I don't think this is a 'good guy' thing to do, although I suppose it could in principle be what's best for the company. Having said that, my guess is that this last one has the smallest amount of commercial value, since it turns what might be a few months of work into a tiny part of a bigger piece of software; it's an investment that probably ranges (when overheads are considered) from $5-50k that has no value at all unless someone else finds the same bug. But if someone else finds the bug, they could as easily be another security researcher as a bad guy, and then you've kinda lost out. Have I missed anything here?
  - tptacek 11y ago
    In this case we're not even talking about a vendor not getting access to a bug found by a third party (though that does happen). We're talking about a series of vendors notified ahead of time who now expect to have a say in how the researcher notifies others. The general response a lot of vuln researchers have to this kind of sniping is that it should be directed to the person who wrote code after, say, 1995 that directly edited /etc/passwd instead of rebuilding and linking it.

wcummings 11y ago

An exploit as the fruit of someone's labor is non-trivial, often holding significant monetary value. They (exploit authors) have no obligation to release it to the vendor at all, let alone for free and "responsibly". Is the unpaid labor scheme you're describing "ethical"? If vendors want "responsible disclosure", they can simply buy exploits at market value.

CHY872 11y ago
Sounds great, but doesn't really work with open source software (unless I have some wires crossed). Who is supposed to pay for an exploit in (say) MariaDb? The value to a sufficiently motivated black-hat organisation is surely far higher than the value to any one user of MariaDb, no matter how big they are.

davidgerard 11y ago

>Responsible disclosure is intended to be ethical, the opposite is ... well, irresponsible. It turns out the name was chosen for its connotations, i.e. to sound good. If you call it "coordinated disclosure" it doesn't come into the discussion cheating.

mpdehaan2 11y ago
The points stand on their own, and I think it's useful to have a phrase that markets the practice. I personally view it as irresponsible regardless of whether we called it "Foo Disclosure". I do view sharing the exploit on the patch date irresponsible irrespective of the term. I believe the name was chosen well, and I don't think it deserves painting with "PATRIOT ACT" type brush. I've dealt with commercial firms as well as non-commercial firm disclosures, and really working with people who report security issues could go a LOT smoother. A lot of those experiences did not go well, but it would be wrong for me to make generalizations. Business here on either side doesn't matter; the user is all that matters, and it shouldn't be about getting "credit", earning points, or being done with something quickly. I think a lot of people think this is a game or something, and it's really not. Real systems and real people's data are on the line.

tptacek 11y ago

"Responsible disclosure" is a term of art coined by a group of vendors and consultants with close ties to vendors. Baked into the term is the assumption that vendors have some kind of proprietary claim on research done by unrelated third parties --- that, having done work of their own volition and at their own expense, vuln researchers have an obligation to share it with vendors. Many researchers do share and coordinate, as a courtesy to the whole community. But the idea that they're obliged to is a little disquieting. If vendors want to ensure that they get some control over the release schedules on their flaws, they can do what Google does and pay a shitload of money to build internal teams that can outcompete commercial research teams. Large companies that haven't come close to doing that shouldn't get to throw terms like "responsible disclosure" around too freely.

CHY872 11y ago
Although I take your point of principle, I'm not really sure I see any incentive to not share vulns. From what I can think, the options are: 1) Actively exploit - I think we can agree that providing it to someone who will actively exploit is ethically dubious, or at least can be classified as irresponsible? 2) Share with the vendor. Ethically, this is fine. 3) Do nothing with it. Ethically, this is fine, although pointless. 4) If you make software that's supposed to detect and/or block the use of such vulnerabilities, add it to the detection system. I don't think this is a 'good guy' thing to do, although I suppose it could in principle be what's best for the company. Having said that, my guess is that this last one has the smallest amount of commercial value, since it turns what might be a few months of work into a tiny part of a bigger piece of software; it's an investment that probably ranges (when overheads are considered) from $5-50k that has no value at all unless someone else finds the same bug. But if someone else finds the bug, they could as easily be another security researcher as a bad guy, and then you've kinda lost out. Have I missed anything here?
- tptacek 11y ago
  In this case we're not even talking about a vendor not getting access to a bug found by a third party (though that does happen). We're talking about a series of vendors notified ahead of time who now expect to have a say in how the researcher notifies others. The general response a lot of vuln researchers have to this kind of sniping is that it should be directed to the person who wrote code after, say, 1995 that directly edited /etc/passwd instead of rebuilding and linking it.