7 ms·

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

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.

lizmat 7y ago
This is not a bug. This is irresponsible behaviour on the side of Tesla, providing hardware that is so open to abuse. With potential effects to the grid as well.
- optimiz3 7y ago
  How is unintended behavior not a bug?
  - Chyzwar 7y ago
    A bug is when something is not working as intended. Tesla's intention was to quickly deliver without considering the security aspects of the product. This is potentially dangerous as attacker can just drive around hacking power walls and schedule an attack on the grid.
    - optimiz3 7y ago
      > Tesla's intention was to quickly deliver without considering the security aspects of the product. [Citation needed] You're assigning intentionality where incompetence would suffice.
      - FireBeyond 7y ago
        I would argue that "building, and leaving open" Wifi connectivity that is not even remotely obfuscated is proof in itself of "failure to consider security aspects".
        drdaeman 7y ago
        Well, to be fair and comparing to not having a password at all - as they put those passwords in place they have somehow tried to protect it. Or make it look protected. 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.
  - ivanbakel 7y ago
    Complete negligence in security is hardly the kind of thing people think about as "bugs". The larger problem is that Tesla has put out software without any sensible considerations for security - that the result behaves badly can't really be called unintended behaviour, unless you are allowed to design software by pipe dream.
  - dx87 7y ago
    This is unintended behavior in the same way that a locksmith leaving a copy of a key under your doormat after installing a new lock is unintended behavior. They didn't intend to cause a security issue, but they also didn't care enough to make sure that what they were doing was safe.
    - optimiz3 7y ago
      Unauthorized access (in the legal sense) is definitely unintended, regardless of whether it's caused by weak design or code defect. 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.
  - Someone1234 7y ago
    If it is documented in the manual[0][1] is it a "bug?" I think the design is poor (bad default WiFi password, WiFi always on, inverting sensors with no sanity checks) but this is how it was designed to work, it is officially documented as doing so. 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/monitoring-from-home-network https://www.tesla.com/support/energy/powerwall/own/monitorin... [1] http://azmag.gov/Portals/0/Documents/MagContent/Tesla_Powerwall%202_AC_Utility_Documentation.pdf?ver=2018-02-22-161139-873 http://azmag.gov/Portals/0/Documents/MagContent/Tesla_Powerw...
    - JaRail 7y ago
      Not having any limits on that invert setting is definitely a security/safety bug. 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.
  - AnthonyMouse 7y ago
    It's not clear that most of this is even "unintended behavior" rather than just abuse. It's like calling it a "hack" to fill water balloons with electrically conductive fluid and throw them at a substation. The people responsible for stopping you from doing that are the police, not the makers of water balloons. The worst thing they did was the default password.
- mlindner 7y ago
  Nonsense. You can twist any bug into "irresponsible behavior".
FireBeyond 7y ago
"Responsible disclosure" is an invention of vendors who want you conforming to their policies and timelines (and more). 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.
- zamadatix 7y ago
  You're always welcome to disclose to the company and follow your own timelines and policies. Presumably this doesn't change whether you tell the company first or post it on your GitHub. Shitty either way but irrelevant.
- corndoge 7y ago
  You can do responsible disclosure without following a vendor's timeline. Project Zero comes to mind. It's not like the only options are either dropping 0 days or doing exactly as the vendor says. Simply give a date. 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.
- kortilla 7y ago
  > "Responsible disclosure" is an invention of vendors who want you conforming to their policies and timeline 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.
  - FireBeyond 7y ago
    Some interesting commentary: https://news.ycombinator.com/item?id=14010010 https://news.ycombinator.com/item?id=14010010 https://news.ycombinator.com/item?id=12308246 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!
setr 7y ago
This doesn't really even seem like much of a disclosure to be had. The system is mostly open without authentication, and what little auth exists is behind a trivial-to-break password. I mean hell, the main "hack" is looking at the API calls.
simion314 7y ago
>this is pretty irresponsible disclosure. 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.
- dfabulich 7y ago
  You're worried about future customers, but what about Tesla's existing customers? For their sake, researchers should at least give the company a chance to respond and fix the issue before public disclosure. 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?
  - simion314 7y ago
    I would agree if and only if is a super hard to find issue, but if any curious teenager can find and abuse this then keeping is secret is making more harm. 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.
raven105x 7y ago
Irresponsible disclosure is releasing products and services with flaws like these onto the open market - the rest is corporate doublespeak.
newnewpdro 7y ago
These issues seem fairly obvious to me. Anyone interested in powerwall vulnerabilities would find them trivially. 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.
- CivBase 7y ago
  > Anyone interested in powerwall vulnerabilities would find them trivially. 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.
- marvin 7y ago
  It can also give you a five- or six-figure payout and prevent unsuspecting customers of being hit by a disrupting and damaging attack, causing unnecessary economic damage. IMHO, choosing the priority of embarrassing someone rather than give them a 24-hour window of notice to avoid this would be a shitty move. 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.
  - FeepingCreature 7y ago
    Not like they couldn't have done that before now.
peteradio 7y ago
What is the bug exactly? Its not like there is some complex sequence to trigger any of this shit, its just sitting there because it's a terrible unsafe design. This is more of a critique of design than any zero day bug post. This is all in the goddamn manual.
sneak 7y ago
There is no such thing as irresponsible disclosure. You are allowed and encouraged to publish your security research WHENEVER YOU FEEL LIKE. 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.
- CivBase 7y ago
  > 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.
  - sneak 7y ago
    The vendor’s existence and actions are irrelevant to whether or not it’s okay to publish your research at any time. It is never irresponsible to disclose one’s research in public, in full. Vendors don’t factor in to it at all.
    - HereBeBeasties 7y ago
      Their customers do, though, and that's the whole point. Without giving people a short, reasonable time to patch, you're part of the problem, not part of the solution. For what it's worth, you are also coming across as something of a zealot, rather than a reasonable person who sees the world in shades of grey.
      - sneak 7y ago
        The burden of proof lies with the person who says publishing research and making it immediately available to those it directly affects is irresponsible. It is not. 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.
bildung 7y ago
> If not, this is pretty irresponsible disclosure. Tesla was the institution that irresponsibly shipped broken hardware. Don't shoot the messenger.

lizmat 7y ago

This is not a bug. This is irresponsible behaviour on the side of Tesla, providing hardware that is so open to abuse. With potential effects to the grid as well.

optimiz3 7y ago
How is unintended behavior not a bug?
- Chyzwar 7y ago
  A bug is when something is not working as intended. Tesla's intention was to quickly deliver without considering the security aspects of the product. This is potentially dangerous as attacker can just drive around hacking power walls and schedule an attack on the grid.
  - optimiz3 7y ago
    > Tesla's intention was to quickly deliver without considering the security aspects of the product. [Citation needed] You're assigning intentionality where incompetence would suffice.
    - FireBeyond 7y ago
      I would argue that "building, and leaving open" Wifi connectivity that is not even remotely obfuscated is proof in itself of "failure to consider security aspects".
      - drdaeman 7y ago
        Well, to be fair and comparing to not having a password at all - as they put those passwords in place they have somehow tried to protect it. Or make it look protected. 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.
- ivanbakel 7y ago
  Complete negligence in security is hardly the kind of thing people think about as "bugs". The larger problem is that Tesla has put out software without any sensible considerations for security - that the result behaves badly can't really be called unintended behaviour, unless you are allowed to design software by pipe dream.
- dx87 7y ago
  This is unintended behavior in the same way that a locksmith leaving a copy of a key under your doormat after installing a new lock is unintended behavior. They didn't intend to cause a security issue, but they also didn't care enough to make sure that what they were doing was safe.
  - optimiz3 7y ago
    Unauthorized access (in the legal sense) is definitely unintended, regardless of whether it's caused by weak design or code defect. 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.
- Someone1234 7y ago
  If it is documented in the manual[0][1] is it a "bug?" I think the design is poor (bad default WiFi password, WiFi always on, inverting sensors with no sanity checks) but this is how it was designed to work, it is officially documented as doing so. 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/monitoring-from-home-network https://www.tesla.com/support/energy/powerwall/own/monitorin... [1] http://azmag.gov/Portals/0/Documents/MagContent/Tesla_Powerwall%202_AC_Utility_Documentation.pdf?ver=2018-02-22-161139-873 http://azmag.gov/Portals/0/Documents/MagContent/Tesla_Powerw...
  - JaRail 7y ago
    Not having any limits on that invert setting is definitely a security/safety bug. 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.
- AnthonyMouse 7y ago
  It's not clear that most of this is even "unintended behavior" rather than just abuse. It's like calling it a "hack" to fill water balloons with electrically conductive fluid and throw them at a substation. The people responsible for stopping you from doing that are the police, not the makers of water balloons. The worst thing they did was the default password.
mlindner 7y ago
Nonsense. You can twist any bug into "irresponsible behavior".

FireBeyond 7y ago

"Responsible disclosure" is an invention of vendors who want you conforming to their policies and timelines (and more). 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.

zamadatix 7y ago
You're always welcome to disclose to the company and follow your own timelines and policies. Presumably this doesn't change whether you tell the company first or post it on your GitHub. Shitty either way but irrelevant.
corndoge 7y ago
You can do responsible disclosure without following a vendor's timeline. Project Zero comes to mind. It's not like the only options are either dropping 0 days or doing exactly as the vendor says. Simply give a date. 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.
kortilla 7y ago
> "Responsible disclosure" is an invention of vendors who want you conforming to their policies and timeline 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.
- FireBeyond 7y ago
  Some interesting commentary: https://news.ycombinator.com/item?id=14010010 https://news.ycombinator.com/item?id=14010010 https://news.ycombinator.com/item?id=12308246 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!

setr 7y ago

This doesn't really even seem like much of a disclosure to be had. The system is mostly open without authentication, and what little auth exists is behind a trivial-to-break password. I mean hell, the main "hack" is looking at the API calls.

simion314 7y ago

>this is pretty irresponsible disclosure. 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.

dfabulich 7y ago
You're worried about future customers, but what about Tesla's existing customers? For their sake, researchers should at least give the company a chance to respond and fix the issue before public disclosure. 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?
- simion314 7y ago
  I would agree if and only if is a super hard to find issue, but if any curious teenager can find and abuse this then keeping is secret is making more harm. 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.

raven105x 7y ago

Irresponsible disclosure is releasing products and services with flaws like these onto the open market - the rest is corporate doublespeak.

newnewpdro 7y ago

These issues seem fairly obvious to me. Anyone interested in powerwall vulnerabilities would find them trivially. 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.

CivBase 7y ago
> Anyone interested in powerwall vulnerabilities would find them trivially. 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.
marvin 7y ago
It can also give you a five- or six-figure payout and prevent unsuspecting customers of being hit by a disrupting and damaging attack, causing unnecessary economic damage. IMHO, choosing the priority of embarrassing someone rather than give them a 24-hour window of notice to avoid this would be a shitty move. 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.
- FeepingCreature 7y ago
  Not like they couldn't have done that before now.

peteradio 7y ago

What is the bug exactly? Its not like there is some complex sequence to trigger any of this shit, its just sitting there because it's a terrible unsafe design. This is more of a critique of design than any zero day bug post. This is all in the goddamn manual.

sneak 7y ago

There is no such thing as irresponsible disclosure. You are allowed and encouraged to publish your security research WHENEVER YOU FEEL LIKE. 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.

CivBase 7y ago
> 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.
- sneak 7y ago
  The vendor’s existence and actions are irrelevant to whether or not it’s okay to publish your research at any time. It is never irresponsible to disclose one’s research in public, in full. Vendors don’t factor in to it at all.
  - HereBeBeasties 7y ago
    Their customers do, though, and that's the whole point. Without giving people a short, reasonable time to patch, you're part of the problem, not part of the solution. For what it's worth, you are also coming across as something of a zealot, rather than a reasonable person who sees the world in shades of grey.
    - sneak 7y ago
      The burden of proof lies with the person who says publishing research and making it immediately available to those it directly affects is irresponsible. It is not. 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.

bildung 7y ago

> If not, this is pretty irresponsible disclosure. Tesla was the institution that irresponsibly shipped broken hardware. Don't shoot the messenger.