I get what you mean about "responsible disclosure" leaving users in the dark here but I'd feel much better if you'd just tell me there's a problem with my door before you put it in the neighbourhood news bulletin.
To make it worse, the vendor has the means to inform every user whereas you have the means to inform some tiny subset.
I see this as a discussion of trade-offs whereas you seem to see this as an obvious truth on your side of the argument. That's the only part that concerns me.
No, it's like going on TV and telling everyone that a certain brand of lock, which you happen to use, is easily circumvented with a Bic pen. Feel free to get a new lock, or do something else to increase your security if you feel it's warranted, as the lock isn't good protection, and it wasn't prior to the announcement either.
You might find this[1] relevant. This is how bad locks can be. Would you rather use this lock in ignorance, or immediately replace it? Particularly of note is the 20 seconds or so starting at 4:10, where he makes it very obvious just how bad this lock is. Also note how he says "Geez, keep sending me stuff like this and you'll get me sued by Master Lock again."
What I don't want you do is secretly working with the vendor of my lock to fit some kind of solution to their problem into their product shipping schedule.
You won't be setting your deadbolt because, guess what, the guy who found the problem told your local Linux Users' Group, not you. And you don't attend your local Linux Users' Group.
If you were telling everyone that would be another thing.
I don't like telling vulnerability researchers what to do. Of all the ethical issues involved in vulnerability disclosure, the most important to me is the fact that these researchers are doing free work for the vendors, who bear all the obligations of ensuring that they're not shipping vulnerabilities in the first place. I think these debates about "disclosure ethics" mostly serve the vendors, who want to deflect from discussions about how they manage to ship vulnerabilities that third parties can find.
But if I had to have a problem with any disclosure process, it's the "secret cabal" model, which has always been an problem for me, all the way back into the 1990s with things like the CORE list.
Twitter is the equivalent of your local LUG in the scale of things. My mum is not reading Twitter for security news, or even at all. What my mum is doing, is having her stuff update. And my dad's no different.
It might as well be some presentation at DEFCON. I want my vendor to disable functionality that's vulnerable. And I want them to be given a chance to do that. If you feel you are adequately warning users by fully disclosing via a Twitter post then so be it. I think I've made all the arguments I have to make on the topic. If they are insufficient, then that is where I must leave it.
To anyone reading afterwards who may not be sure about my position, I feel positively about how this vulnerability was handled.
Not really. Any serious vulnerability in a widely used product disclosed by twitter announcement makes it into the mainstream media in no time and prompts a response by the vendor (if one had not been forthcoming already). Your local LUG, less so.
I would rather have the former. Also, I didn't pick the Bic pen thing randomly. Certain Kryptonite locks were once famously demonstrated to be Bic pen unlockable.
If a vulnerability in your lock is found and the lock manufacturer buys you a new lock within a week, do you stop trusting that manufacturer?
What is a serious problem is subjective. The right amount of time to wait is subjective. In both cases, there will be people that are unhappy with how they were or weren't informed. Instead of some select group of people deciding how important the fix is and when it will be fixed, announcing immediately empowers the public.
If you feel that the vulnerability is big, and the company is taking it seriously enough, you give them an honest chance, otherwise if they slack or hum and haw, you go to the public.
The nuance here is that we trust the person who discovered the hole to make subjective judgements about the severity of it and the company's response, and we force the company to be more transparent than usual to the person who discovered it about how they are working/nature of the code fix. But maybe that could be a good thing?
This. I fully agree with this. Obscurity is a good form of security in a temporary sense. But vulnerabilities should ALWAYS be disclosed to the public, for a number of reasons. The question is when. Disclosing does a couple things: 1) We see a company fixes them in a timely manner, which gives us trust in services that we use (and the opposite if they fail to) 2) other companies don't make the same mistakes because now the vulnerability is googleable and quickly becoming public knowledge.
Of course not. In our analogy here, if the lock maker isn't issuing even a statement then hell no you shouldn't trust them. But in this case the locksmith fixed the lock and reissued the lock within a week.
> What is a serious problem is subjective.
Yes an no. There is a gray area. But what isn't is: lives, A TREASUREBOX OF PASSWORDS, anything that can cause physical damage, and anything that can significantly compromise a user's safety.
To be clear: in another post I said you should ALWAYS (read as "\Huge{ALWAYS}")publicly disclose. So that others don't make the same mistake. But obscurity can be useful in the short run.
Announcing immediately DOES NOT empower the public. They are not rational and quick to fear. ALL (EVERY SINGLE ONE) companies have vulnerabilities. What is important is if they fix them in a timely manner or not. SEEING that a company does fix a problem quickly empowers the company AND the user, because they find they have a company they can trust. Immediate disclosure only empowers the adversary.
Your statement would be true IF it were possible for software to be invulnerable. Since ALL software (and hardware) is vulnerable it is perfectly reasonable to give the owner of said software/hardware a reasonable time to fix the issue before releasing to the public. I fully believe you should always release to the public, but obscurity is a good temporary measure.
Remotely turning off a pacemaker is the ultimate example of empowerment. If I had a pacemaker, I would want to be informed immediately of a vulnerability, along with everyone else. Assuming it's a proximity-based attack, I'd have the option of driving to a rural area and booking a motel until the vendor deploys a fix.
This is obviously an extreme example, but addressing the most extreme example might be the best way to address all the rest.
How would I hear about it? Because HN, Reddit, and Twitter would all blast the information to everyone, along with "warn anyone you know who has a pacemaker." Even if I weren't technologically literate, someone close to me would tell me.
This is strictly preferable to the alternative: If the vulnerability is kept secret, my life would be in the hands of a select few who (a) know about the vulnerability and (b) may or may not use this information to their advantage.
When an independent security researcher informs a company about a vulnerability, the researcher has almost no transparency into how the company is responding to the report or what the timeline is for a fix. (HackerOne has made this a bit better, but most companies still don't have public bug bounty programs.) In the case of a pacemaker, it's very likely that the only thing the security researcher will hear is "Thank you for informing us. We are working urgently to deploy a fix" followed by a month of silence. This leads to the researcher doing increasingly desperate things to bring attention to the issue, such as emailing other security researchers in private. But an independent security researcher has no way of knowing whether the person they're emailing is trustworthy, nor can it be guaranteed that their conversation isn't being spied on. The researcher is also likely to tell someone (their husband/wife, their colleagues, etc) who are all trusted to keep it secret.
The responsibility for the pacemaker being able to kill me is squarely on the vendor, not the researcher. I would argue that the researcher has an ethical obligation to inform me, first and foremost, so that I can protect myself from the threat as quickly as possible.
When my life is on the line, giving me a chance to save it is much better than leaving it up to someone else to secretly guard it.
Some people might feel differently. For example, maybe they'd want to remain unaware that their pacemaker could kill them. But the point is that it's not a clear-cut issue.
Honestly, in that situation I would probably do nothing, since the chance that anyone would maliciously target me with a proximity-based attack is so small that it's more productive to be worried about being struck by lightning. But what if it wasn't proximity-based? Let's ratchet up the severity: What if somehow the pacemaker was connected to wifi by design, and someone gained control over whatever central server it was connecting to? In that case, I would want to be informed so that I could disable my wifi rather than trust that the server remains secure while a fix is deployed.
This all may seem unrealistic, but computing is still in its infancy. What about self-driving cars? I'd want to know immediately if someone could remotely gain control over my car so that I can not get in one. Ditto for planes.
My mind is open on the topic, so I assure you that if you try to persuade me otherwise, it will be a productive conversation. But it's hard to imagine a scenario where I'd rather not know of a threat. Can you think of one?
The only thing that comes close is if an entire city could somehow be destroyed remotely by any random troll on the internet. But in that case it might still be better to warn everyone immediately so that they can flee from the threat that was somehow constructed in their back yard, rather than keep them ignorant ostensibly for their protection and tell them later "By the way, you and your family were in serious danger."
Currently there have been no cases seen in the wild, how do you move forward? Do you give the company a chance to fix the problem before it is seen in the wild? I think so, and here is why.
If you fully disclose you WILL see the hack in the wild because of its ease to execute and there are malicious people out there. What does the public do? Not go into work for a month? People can't do that. Buy a new car? People can't just buy new cars. They are too expensive and it isn't like a dealer will want to do a trade in for a dangerous car.
Let's say you just tell the public that there is an easy to reproduce hack, and you fully disclose to the company. This can still be a dangerous thing because now that people know there is a powerful hack and they will be looking. Malicious actors will be quick to use it too, because they know it will be patched soon. It isn't unreasonable to think that the hack can be found before it can be fixed and a patch issued.
Now let's say that you just disclose to the responsible party. There aren't many people looking for the hack. Malicious actors that might know about it (definitely few at this point), will be wary to use it because if it is used then the people will find out about it. In the mean time the company patches it, issues an OTA update, and we never see the attack in the wild (or maybe once or twice). We then tell the public so that no one makes the same mistake. By doing it this way you minimize the chance of the hack being used. This method IS protecting your life better than you could do on your own.
We are presented with a problem if the responsible party brushes off the researcher. It is the responsibility of the researcher partially disclosing to the public. So now we're in the second case presented above. But now there is more power to the public. From a legal standpoint you can prove recklessness or malice by the responsible party and a lawsuit will be much easier. The company can be required to replace the vehicle, provide a temporary replacement, or buy it back. Whatever happens it will go much smoother in court than if one of the first two events happened.
The key here is that we need trust. No system is invulnerable and it would be naive to think there is one. What the trust comes from is that the company producing the product you are using fixes the issue quickly. The trust is that they are doing what they can to ensure the safety of the users.
Of course they have options. It's up to them to choose whether to get into a dangerous car. They can arrange to ride-share, or book a taxi, or ask a favor from a friend. And even if they have no options, the vulnerability researcher didn't make them less safe by disclosing immediately. The car company made them unsafe by shipping a car that could kill them.
Tangentially related, but you may find that the term "responsible disclosure" has covertly influenced your thinking, as it did mine: https://news.ycombinator.com/item?id=12308246 It's easy not to notice.
> We are presented with a problem if the responsible party brushes off the researcher. It is the responsibility of the researcher partially disclosing to the public. So now we're in the second case presented above. But now there is more power to the public. From a legal standpoint you can prove recklessness or malice by the responsible party and a lawsuit will be much easier. The company can be required to replace the vehicle, provide a temporary replacement, or buy it back. Whatever happens it will go much smoother in court than if one of the first two events happened.
The company will undoubtedly be required to fix the vehicle anyway, if only to save their brand. Just because someone revealed the existence of a problem doesn't absolve them of any responsibility.
You make some good points, and the conclusions are logical and well-reasoned. Unfortunately I think we disagree on the central point: "This method IS protecting your life better than you could do on your own." Under no circumstances would I want to get into a car that an sdr could control -- this is the ultimate protection -- and the only way to ensure that is to be informed immediately.
What we're talking about here is the discovery of a vulnerability. Not that the company knowingly shipped the product with this issue.
Security is a constant cat and mouse game. Security through obscurity is an effective method in the short run. A company cannot and will not be responsible for shipping a car that could be hacked unless security researchers could show that there was gross negligence.
>Under no circumstances would I want to get into a car that an sdr could control
I suggest never entering a car with a computer in it. This likely means the car you own. Basically if your car has power steering and power braking then it can be hacked.
It depends on the specifics of what's being exploited but in general I think a short delay between informing those who can fix it and those who will exploit it is generally more moral.
In the case of the Lastpass exploit it would've been to not use Lastpass for a few days. That's one benefit of direct disclosure to the user.
I'd much rather transcribe my financial account passwords to paper, or not log in for a couple days than have multiple months where a vulnerability might be exploitable
"Hey neighbor, nevermind how I know this, but I can open your door with a Bic pen and steal all your stuff if I wanted to"
"Well no one is going to try that. So I'm safe"
Post instructions
But if the person asks for help to prevent it, and especially if you're being paid (like Travis) or a good neighbor, help them before you post instructions. So the instructions you post aren't useful to break into your neighbor's house.
You tell them.
>>Do you spend time helping them all?
No
>>Is it more ethical to help your friends over the public at large?
It is more ethical to help the major players. We're talking about a company that holds a significant portion of users data. If we found Master Lock had a vulnerability, we'd expect them to fix it (we wouldn't expect them to replace every users' lock for a number of reasons that are different from a software vulnerability, but it wouldn't be unreasonable for them to notify users and/or provide a coupon). It also wouldn't be unreasonable to wait for Master Lock (who controls a significant portion of the market) to fix it before making it public. Making it public means everyone can fix it. But let the majority have an attempt to fix it before letting the public, and malicious factions, know.
1. Inform the company of the vulnerability
2. Offer a limited disclosure of the vulnerability to the public/whomever you want, without giving away details of the vulnerability, as these would make an attack from an adversary more possible while the company fixes the bug.
3. After the company patches the bug, do whatever you want.
edit: I guess it would be important to ask this as well so we're not just going in circles, of the three general categories of ethical systems, would you say you prescribe to virtue, consequentialist, or deontological ethics?
I am consequentialist in some situations and deontological in others, though I identify more strongly with deontological ethics.
That is much more ethical. However, I am not sure that I believe it is something that would pass my threshold for clearly ethical (not your words, mine). You would need to weigh the damage to the company and consumer knee-jerk against the ability for consumers to make an informed decision about what they're willing to risk. In this case, maybe LastPass deserves for consumers to know immediately. They seem to have an extremely buggy program with a number of disclosed vulnerabilities. It's hard to know whether other programs are necessarily better though. Another factor that you should account for against disclosing is that stating the nature of the vuilnerability could potentially make it easier for someone to exploit. Do you think Tavis could find a vuln easier if I told him it was an RCE vs a CSRF bug? I do.
This statement, while true, makes me sad.
Immediately disclosing allows customers to take action to protect themselves in case someone else is already exploiting the bug. Waiting to disclose is being peddled by the corporate agenda as "the ethical thing to do" because it makes vendors look bad.
Here's typically what happens. You disclose a bug, company fixes it for next release and puts a footnote in the release notes. Nobody ever looks to see if it was exploited because the instinct is to bury it. Customers aren't widely notified and the seriousness is downplayed because "the bug is already fixed" . In the meantime the software was vulnerable for up to three months when it didn't have to be.
If you disclose immediately there's a temporary panic as everyone does mitigating measures (which is how it should always be done!!!). the company is under tremendous pressure to out a patch in a matter of days which they usually do. Then you get yelled at by the company for making them look bad and "putting their customers at risk" even though the customers are provably safer because they were only vulnerable for a few hours
Source?
What's really more dangerous, an extra week with a vulnerability that might be known, or two hours with a vulnerability everybody knows about?
Who's really more likely to see that disclosure on your personal Twitter account, every single (potentially non-technical) user of software you aren't even related to, or a few black hats who know you like to hack and brag?
Yes, it also makes companies look better, but in this case my anti-corporate agenda needs to take a back seat.
I'd rather an exploit stay secret so there's a chance that someone doesn't use it against me, rather than telling everyone the exploit and hoping someone fixes it fast enough.
Disclose it to the company, and give them a hard time limit.
Here are a bunch of tptacek comments on the topic:
--
"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.
--
"Responsible disclosure" is a marketing term. Linus may be wrong about the importance of security flaws relative to bugs, but that doesn't validate the self-aggrandizing omerta of security researchers.
Vendor "coordination" of security flaws often works to the detriment of users. For one thing, cliques like vendor-sec gossip and share findings with the "cool kids", ensuring that every interested party but the operators knows what's coming a week before the advisories are published. For another, it substitutes the judgement of people like you --- who, no offense, don't run real world systems or make real world risk assessments about real assets --- for the judgement of the people who are not like you, but who could potentially disable or work around vulnerable systems far in advance of "coordinated patches".
--
The process of "responsible disclosure" gives product managers latitude, because it effectively dictates that researchers can't publish until the vendor releases a fix. The vendors almost always decide when to release fixes. When a researcher publishes immediately, vendors are forced to fix problems immediately. A small window of vulnerability is created ("small" relative to the half life of the vulnerability, which depends on all sorts of other things) where less-skilled attackers can exploit the problem against more hosts.
On the other hand, in the "responsible" scenario, many months will invariably pass before fixes to known problems are released. During that longer window, anybody else who finds the same problem (and, obviously, anyone who had it beforehand) can exploit the vulnerability as well. Furthermore, full disclosure creates a norm in which vendors are forced to allocate more resources to fixing security problems, instead of waiting half a year or more. This costs vendors. But the alternative may cost everyone else more. It depends on how well-armed you think organized crime is.
Finally, there's the issue nobody ever seems willing to point out. If you disclose immediately, lots of people can protect themselves immediately: by uninstalling or disabling the affected software.
--
You are unlikely to find anyone in the "community of responsible security researchers" to say anything negative about Tavis Ormandy. It is way over the top to imply that he's not "halfways mature".
You will, on the other hand, find plenty of people with real reputations in the industry at stake (unlike yours, which is influenced not one whit by anything you say about disclosure) who will be happy to explain why "responsible disclosure" is damaging the industry. It's not even a hard argument to make. The dollar value of a reliable Windows remote is too high to pretend that bona fide researchers are the only people who will find them. Meanwhile, because product managers at large vendors are given the latitude to fix problems on the business' schedule instead of the Internet's, people get to wait 6-18 months for fixes to trivial problems.
Personally, without wading into "responsible" vs. "full" disclosure, I will point out that vulnerability research has made your systems more secure; the manner in which the vulnerabilities were uncovered has very little to do with it. You are more secure now because vendors and customers pay to have software tested before and after shipping it.
--end--
This exchange on why the term "responsible disclosure" is Orwellian is also worth reading: https://news.ycombinator.com/item?id=12308246
All of that is just a small portion of everything he's said: https://hn.algolia.com/?query=by:tptacek%20responsible%20dis...
I think there are sufficiently many persuasive arguments that it's very difficult to claim that someone who informs the world of the existence of a bug is doing more harm than good, regardless of how that information is made public. And if they're doing more good than harm, it's probably ethical.
uh, no. For example is unethical to sacrifice a few human lives to do horrible experiments ignoring their will to save many more, right?