Did they even try to submit these issues to Tesla? They have a bug bounty program and have been reasonably good about patching issues in vehicle software. If not, this is pretty irresponsible disclosure.
Tesla is also "good" at disabling aspects of people's property (like ethernet ports, or ability to receive future firmware updates) when they dislike what people find "wrong" or otherwise in Tesla software.
Presumably this doesn't change whether you tell the company first or post it on your GitHub. Shitty either way but irrelevant.
At the end of the day the point of security research is to make things more secure. Oftentimes that is best achieved by working with the vendor.
No it’s not. It’s an invention of ethical hackers and academic security researchers who are mature enough to realize that dropping 0-days to the public is worse for society than giving the vendor a reasonable opportunity to fix it.
“Economics of information security” is a field that publishes some studies about vulnerability disclosure strategies and maximizing the social good.
https://news.ycombinator.com/item?id=14010010
https://news.ycombinator.com/item?id=12308246
> That may feel good to say, but as someone whose job it was to find these kinds of bugs in software from companies ranging from tiny startups to financial exchanges to major tech vendors, this is a kind of carelessness shared by virtually everyone shipping any kind of software anywhere.
> That said, the term "responsible disclosure" is Orwellian, and you should very much avoid using it.
> It's coercive. It redefines language to make any handling of vulnerabilities not condoned by the vendors who shipped those vulnerabilities "irresponsible", despite the fact that third parties who discover vulnerabilities have no formal duty to cooperate with those vendors whatsoever.
> The better term is "coordinated disclosure". But uncoordinated disclosure is not intrinsically irresponsible. For instance: if you know there's an exploit in the wild for something, perhaps go ahead and tweet the vulnerability without notice!
It seems you disapprove of the phrase "responsible disclosure" because it's ambiguous and can be used as a cudgel. That's no different than the term "Orwellian", which is ambiguous and can be used as a cudgel.
All people are saying is that it's better to give the vendor a heads up before releasing an exploit. Maybe they have something to tell you that might cause you to delay; maybe not. Surely responsible disclosure implies to most people some amount of due diligence in choosing a timeline for disclosure. If you don't give a vendor any opportunity to discuss, there's been no such due diligence on your part.
This is like saying that a glock can be used as a weapon. Yes, it was carefully designed to be one.
>We must secure the existence of our people and a future for white children
This might also be ambiguous, but we all understand the genocidal connotations.
Ah yes, because using the term "responsible disclosure" is very clearly analogous to being a white supremacist.
There's no need to be so ridiculously dramatic -- "responsible disclosure" was objectively the term-du-jour used by the infosec community until fairly recently. And it's perfectly understandable why the community changed their mind (vendors started co-opting the phrase as a method of shaming researchers for doing the right thing), but you are shooting yourself in the foot by being so aggressive about it. Why not just say "we used to use that term, but we use this other term now because of the following reasons"?
Here's a little historical context https://www.securityfocus.com/columnists/120
I think the 14 words comparison is apt. Without context there's nothing obviously wrong with the 14 words, just like there's nothing obviously wrong with "responsible disclosure".
Releasing anything that can be used to harm the public has ethical implications, period. There is no grey area there. Responsible disclosure is entirely about minimizing impact.
People that don’t like the term don’t like it because they don’t like the idea that there are ethical implications for releasing information.
Do you think there is an ethical gray area to releasing a method to the public to gain access to the secure side of an airport terminal without going through security so guns/bombs can be brought in undetected? What if that method is a software vulnerability in the door locks they use?
> The better term is "coordinated disclosure". But uncoordinated disclosure is not intrinsically irresponsible. For instance: if you know there's an exploit in the wild for something, perhaps go ahead and tweet the vulnerability without notice!
FFS, that’s why the term is “responsible disclosure” and not “coordinated disclosure”. Responsible disclosure is the entire process of determining when and how to inform vendors and/or major users or if to inform them at all. Responsible disclosure is entirely about doing disclosure in the least harming way possible to the public.
Ridiculous. Please don't put out this kind of nonsense. Responsible disclosure is to protect the users of software. Supply chains cannot and do not respond instantaneously. You cannot fix a security problem within microseconds. There MUST be some delay between disclosure to the software provider and the actual release. Otherwise you're just endangering the public. How much delay is certainly a point of discussion, but no one is saying "no delay".
I mean hell, the main "hack" is looking at the API calls.
This is what corporations claim, an example that makes you think about the "irresponsibility" of disclosure is the Intel security bugs, Intel sits quiet for 1 year (and more if it's bribe would have worked) and customers are tricked to buy insecure products. As a possible future customer you would like to know that something is insecure before you buy it , keeping it hidden will just increase the number of affected people.
I agree that a year is too long. I think 30 days is about right, but it depends on how fast the product is selling, how many new customers might be harmed during the 30-day period vs. how many existing customers there are.
How many customers do you think have already purchased a PowerWall, vs. how many would have purchased in the next 30 days?
If your car had a bug where it could be controlled remotely by any teenager with a laptop and a program do you want to know and stop using the car or block it's internet connection or prefer Tesla has it's 90 days to find a fix.
Anyway let's see what harm comes from this being revealed and maybe I will change my mind.
This is potentially dangerous as attacker can just drive around hacking power walls and schedule an attack on the grid.
[Citation needed]
You're assigning intentionality where incompetence would suffice.
But I agree that it indicates that they haven't gave any consideration to it, and in 2019 that doesn't count as trying anymore. At least because we're talking about a well-established hardware and software vendor, not my grandma.
Posting 0-days on GitHub isn't responsible disclosure. The real test will be to see how fast it gets fixed and what the fixes end up being.
I guess it boils down to a definition of the term "bug." But I feel like a lot of the knee-jerk responses (and voting) didn't read the article carefully enough.
It is a core design weakness rather than a "bug" (implying an error) in an actual good design. I think the distinction is subtle but it is there.
[0] https://www.tesla.com/support/energy/powerwall/own/monitorin...
[1] http://azmag.gov/Portals/0/Documents/MagContent/Tesla_Powerw...
The password is a level of incompetence beyond what you'd call a bug. It's clearly following a design decision that was imposed by someone with zero security experience.
The worst thing they did was the default password.
In this case I think the value is in embarrassing Tesla for their gross negligence so they do better in this area before shipping.
When you disclose such things quietly with the vendor, it mostly just saves their face.
Not everyone values saving Tesla's face.
What about those who become invested in powerwall vulnerabilities because they read an article on HN that showed how easy it is?
> When you disclose such things quietly with the vendor, it mostly just saves their face.
I don't see how. They still get put on blast for ever being vulnerable in the first place. If you're goal is to get them in more trouble at the expense of their consumers, then that seems like pretty irresponsible disclosure to me.
> Not everyone values saving Tesla's face.
And not everyone cares one way or another about Tesla. This is about responsible disclosure. It's about protecting the consumers. It has nothing to do with the vendor.
This should be short-term trivially fixable by pushing a password update that sets unique passwords based on a SN -> password mapping stored in a DB at the vendor. You don't need more than 24 hours to do that.
Tesla was the institution that irresponsibly shipped broken hardware. Don't shoot the messenger.
The term “responsible disclosure” is a shady tactic to frame publishing immediately and in full to those affected by the vulnerability as irresponsible. It is not.
What? Have you even tried to understand what responsible disclosure is?
It is about giving the vendor a chance to protect their consumers before teaching the public how to exploit a vulnerability.
The vendor still gets put on blast when the vulnerability is eventually disclosed. But at least there is less risk of the vulnerability being exploited in the mean time.
And if the vendor doesn't fix the vulnerability in a reasonable time frame, they get extra blast. We've seen this happen many times. The recent Valve and Intel incidents stand out to me as good examples.
The side effect that it is available to attackers is also irrelevant to the determination of whether or not it’s irresponsible; it also becomes available to the vendor who shipped it.
This notion of “you have to give the vendor time to patch xor you are irresponsible” is itself bogus. The vendor releasing the patch (prior to publication of the paper) is just as much a drop of the 0day as publishing the paper is.
Burden of proof? This isn't a court case. The overwhelming majority of users will never see a vulnerability write-up, do not have the education needed to understand such a writeup and - even if they saw the writeup and understood it - lack the tools and information to fix a vulnerability in proprietary software.
The vendor only factors in because they are the only one who can fix the issue.
A disclosure like this only helps hackers and the few consumers who are capable of hacking their own product. It hurts everyone else.
> The vendor releasing the patch (prior to publication of the paper) is just as much a drop of the 0day as publishing the paper is.
Who here is arguing against disclosure? We're arguing for responsible disclosure. Once the vendor distributes patch, consumers can actually do something to protect themselves. At that point, you can put the vendor on blast all you want without harming the consumers.