5 ms·

Modern cars run on CANbus. Everything is linked. No, seriously, everything: steering (at low speeds, the park assist can be exploited), brakes, lights, radio, a

Modern cars run on CANbus. Everything is linked. No, seriously, everything: steering (at low speeds, the park assist can be exploited), brakes, lights, radio, a/c. You'd have to go back at least ten years to find cars without it.

lifeeth_ 11y ago
Linked but not linked to the internet by default :)
artmageddon 11y ago
It's true, and it's the whole basis for CAN networks. The whole car runs without a central computer, but rather, a set of microcontrollers for all of the different functions of the car. Every single microcontroller, more or less, broadcasts messages to all of the other ones along the bus. I'd say you'd probably have to go back even further than 10 years as the latest CAN spec, 2.0, was published in 1991.
- joezydeco 11y ago
  But every microcontroller on the network doesn't have to listen to messages from the others. The real problem is that the designers of CANBUS never dreamed of a day when rogue nodes could show up on the network and start broadcasting messages they should not be broadcasting. Automotive embedded systems were closed loops and, aside from perhaps a diagnostic tool in the garage while parked, not susceptible to spoofing messages.
  - tinco 11y ago
    I wouldn't even blame the designers of CAN-bus. The crazy thing is that GM/Chrysler allow media devices and general computers on the CAN-bus without a firewall. It's easy to say that the architecture is flawed, but that's no excuse at all. The CAN-bus allows control of the car, so non-control devices should not be allowed to send control messages on the CAN-bus. It's the same as blaming the insecure architecture of the internet when your password gets snooped, when you should have just used a secure tunnel.
    - joezydeco 11y ago
      The CAN-bus allows control of the car, so non-control devices should not be allowed to send control messages on the CAN-bus. Unfortunately CAN is not as complex as an IP packet. It's essentially a one-wire serial bus with collision detection. Even RS-232 lets you clip the TX line so that a device could listen but not send. You would need to clip the TX before the CAN transceiver, and that's something nobody typically does.
      - tinco 11y ago
        I'm suggesting there would be a hardware device that sits between any device and the CAN-bus. It would simply decode incoming messages, and filter not allowed messages, recode the rest and put them on the bus. I bet you could program an Arduino Nano to do this (as an illustration that it's a fix that shouldn't require more than a few dollars, obviously it'd have to be rugged, robust and reliable for GM/Chrysler to do it).
        jschwartzi 11y ago
        The simplest method is to encode an authentication scheme using digital signatures for each device in the bus, and burn an approved transmitter list into each device such that specific messages have to be signed by a specific MCUs authentication key or it is ignored. Then simply don't add internet-connected hardware to the approved senders list for any high-risk messages. You can then compromise the car at will but none of the other CAN devices will process acceleration messages unless you happen to own an internet-connected accelerator.
        tptacek 11y ago
        Digital signatures are (a) not simple --- the cost and complexity of implementing and verifying them might be as bad as that of switching to a different phy/mac and (b) particularly tricky to do in microcontroller parts.
        11y ago
  - mratzloff 11y ago
    Maybe I don't understand the difficulty. This is a standard services problem that standard software architecture practices would solve. You just need a gateway sitting in front of the CAN bus and any externally exposed services must go through the gateway. Only "safe" services or commands are exposed in this case. Maybe an entire service here, maybe a specific info command to an essential driving service there. The gateway inspects all incoming requests from these external services. All internal commands continue talking through the bus directly. Problem solved.
    - joezydeco 11y ago
      Yes, a gateway is a common solution. Or having two busses (one for engine control and the second for aux functions like HVAC, radio, lighting etc) with a system to pass critical messages between the two. But it's cheaper to use a single bus and just slap everything on there. Or in the case of something like OnStar, realize you can add extra capabilities through firmware and not fully think about the impact when your radio can send unfiltered messages to your ECM.
    - mzs 11y ago
      You do have that gateway, it's likely the radio too. That thing has the most complicated and feature-full code of anything in the car and humans make mistakes when writing even simple software.
acomjean 11y ago
And how would OnStar remotely disable your vehicle or slow it down if it wasn't connected to the network. https://www.onstar.com/us/en/services/security.html https://www.onstar.com/us/en/services/security.html I hope they get this sorted before self driving cars... (50 bitcoin in 20 minutes or your car takes a drive off the pier...)
- ambicapter 11y ago
  That's really the problem...just like feds wanting backdoors that "only they" can access, Onstar thought it was clever and could grant itself powers in software that no one would be able to exploit. Too bad the people who are best at exploiting software aren't likely to work for companies like Onstar (I'm not saying Onstar is disreputable, just probably boring and with a low skill ceiling).
- grkvlt 11y ago
  > 50 bitcoin in 20 minutes or your car takes a drive off the pier I would NOT like to think about what would happen to someone who tried this sort of thing. I expect within seconds of the first accident (or worse, injury, even fatality) causing malware being discovered, the resources of the entire NSA would be being used to track down the author. Then, when found, 'bad day' would not begin to describe the rest of their life. In fact, I can see this sort of thing being validly placed under 'terrorism' and dealt with appropriately. People who randomly attack vehicles being driven around today (brick thrown off bridge over a busy road into windscreen et al) are not the smartest, or have poor self control or other issues, but they are actually quite rare. To pull off an automated hack would require enough intelligence that they can surely understand the consequences. Therefore, this will be done by a genuine psychopath (or sociopath? never quite sure of the terminology) or terrorist group. I think we should be as worried about vehicular-malware-based-death as we are about dying from other terrorist attacks. So yes, I know that means the risk is small, but the general public will over estimate it, and worry inappropriately. That seems to be a matter of education, not technology, though...
pdkl95 11y ago
Then "modern cars" can never be considered safe, and whomever the professional engineers are that signed off on that design have some explaining to do. "market forces" or "following my boss's orders" are not valid excuses; a professional engineer has a duty to ignore such things when considering safety. I suspect whole auto industry needs to re-learn (if they ever learned in the first place) the lesson of the Therac-25 and what "fail safe" means. Some dangerous situations should not be possible. Unfortunately, I suspect the auto industry will choose to learn those lessons the hard way. When people die from someone messing with their steering or brakes remotely, I hope whomever signed off the idea of mixing remote signalling with critical systems is found personally liable for manslaughter.
- abduhl 11y ago
  Does the software industry even have a requirement for professional licensure? If not, then there is no "professional engineer" that signed off on the design and there is no regulatory liability and hence no questions to answer by the engineer. This is one of big problems with the software industry nowadays. It has a role to play in nearly every major industry but does not have the same regulatory hoops to jump through to get into that industry. In this case, I am sure multiple mechanical and electrical licensed professional engineers had to stamp all of the physical components that make up the vehicle but I would be very surprised if any software was ever signed off on by a licensed professional engineer explicitly (there is a case to be made for implied acceptance by the engineer of record for the system that the software runs on but I think it is weak).
  - mmagin 11y ago
    At least in the US, it is entirely plausible that many of the electrical engineers working in a large company on such a product are not licensed professional engineers.
- maxerickson 11y ago
  There are no cars on the road that have brake lines that are tamper proof, so I'm not sure you are setting the bar at the correct level. It will be interesting to watch the ongoing situation with Chrysler: http://www.wired.com/2015/08/chrysler-harman-hit-class-action-complaint-jeep-hack/ http://www.wired.com/2015/08/chrysler-harman-hit-class-actio... If the class action goes forward there will be a legal examination of whether a security flaw that allows remote tampering is a safety defect or not (of course it is, but I mean in the context of liability).

lifeeth_ 11y ago

Linked but not linked to the internet by default :)

artmageddon 11y ago

It's true, and it's the whole basis for CAN networks. The whole car runs without a central computer, but rather, a set of microcontrollers for all of the different functions of the car. Every single microcontroller, more or less, broadcasts messages to all of the other ones along the bus. I'd say you'd probably have to go back even further than 10 years as the latest CAN spec, 2.0, was published in 1991.

joezydeco 11y ago
But every microcontroller on the network doesn't have to listen to messages from the others. The real problem is that the designers of CANBUS never dreamed of a day when rogue nodes could show up on the network and start broadcasting messages they should not be broadcasting. Automotive embedded systems were closed loops and, aside from perhaps a diagnostic tool in the garage while parked, not susceptible to spoofing messages.
- tinco 11y ago
  I wouldn't even blame the designers of CAN-bus. The crazy thing is that GM/Chrysler allow media devices and general computers on the CAN-bus without a firewall. It's easy to say that the architecture is flawed, but that's no excuse at all. The CAN-bus allows control of the car, so non-control devices should not be allowed to send control messages on the CAN-bus. It's the same as blaming the insecure architecture of the internet when your password gets snooped, when you should have just used a secure tunnel.
  - joezydeco 11y ago
    The CAN-bus allows control of the car, so non-control devices should not be allowed to send control messages on the CAN-bus. Unfortunately CAN is not as complex as an IP packet. It's essentially a one-wire serial bus with collision detection. Even RS-232 lets you clip the TX line so that a device could listen but not send. You would need to clip the TX before the CAN transceiver, and that's something nobody typically does.
    - tinco 11y ago
      I'm suggesting there would be a hardware device that sits between any device and the CAN-bus. It would simply decode incoming messages, and filter not allowed messages, recode the rest and put them on the bus. I bet you could program an Arduino Nano to do this (as an illustration that it's a fix that shouldn't require more than a few dollars, obviously it'd have to be rugged, robust and reliable for GM/Chrysler to do it).
      - jschwartzi 11y ago
        The simplest method is to encode an authentication scheme using digital signatures for each device in the bus, and burn an approved transmitter list into each device such that specific messages have to be signed by a specific MCUs authentication key or it is ignored. Then simply don't add internet-connected hardware to the approved senders list for any high-risk messages. You can then compromise the car at will but none of the other CAN devices will process acceleration messages unless you happen to own an internet-connected accelerator.
        tptacek 11y ago
        Digital signatures are (a) not simple --- the cost and complexity of implementing and verifying them might be as bad as that of switching to a different phy/mac and (b) particularly tricky to do in microcontroller parts.
        11y ago
- mratzloff 11y ago
  Maybe I don't understand the difficulty. This is a standard services problem that standard software architecture practices would solve. You just need a gateway sitting in front of the CAN bus and any externally exposed services must go through the gateway. Only "safe" services or commands are exposed in this case. Maybe an entire service here, maybe a specific info command to an essential driving service there. The gateway inspects all incoming requests from these external services. All internal commands continue talking through the bus directly. Problem solved.
  - joezydeco 11y ago
    Yes, a gateway is a common solution. Or having two busses (one for engine control and the second for aux functions like HVAC, radio, lighting etc) with a system to pass critical messages between the two. But it's cheaper to use a single bus and just slap everything on there. Or in the case of something like OnStar, realize you can add extra capabilities through firmware and not fully think about the impact when your radio can send unfiltered messages to your ECM.
  - mzs 11y ago
    You do have that gateway, it's likely the radio too. That thing has the most complicated and feature-full code of anything in the car and humans make mistakes when writing even simple software.

acomjean 11y ago

And how would OnStar remotely disable your vehicle or slow it down if it wasn't connected to the network. https://www.onstar.com/us/en/services/security.html https://www.onstar.com/us/en/services/security.html I hope they get this sorted before self driving cars... (50 bitcoin in 20 minutes or your car takes a drive off the pier...)

ambicapter 11y ago
That's really the problem...just like feds wanting backdoors that "only they" can access, Onstar thought it was clever and could grant itself powers in software that no one would be able to exploit. Too bad the people who are best at exploiting software aren't likely to work for companies like Onstar (I'm not saying Onstar is disreputable, just probably boring and with a low skill ceiling).
grkvlt 11y ago
> 50 bitcoin in 20 minutes or your car takes a drive off the pier I would NOT like to think about what would happen to someone who tried this sort of thing. I expect within seconds of the first accident (or worse, injury, even fatality) causing malware being discovered, the resources of the entire NSA would be being used to track down the author. Then, when found, 'bad day' would not begin to describe the rest of their life. In fact, I can see this sort of thing being validly placed under 'terrorism' and dealt with appropriately. People who randomly attack vehicles being driven around today (brick thrown off bridge over a busy road into windscreen et al) are not the smartest, or have poor self control or other issues, but they are actually quite rare. To pull off an automated hack would require enough intelligence that they can surely understand the consequences. Therefore, this will be done by a genuine psychopath (or sociopath? never quite sure of the terminology) or terrorist group. I think we should be as worried about vehicular-malware-based-death as we are about dying from other terrorist attacks. So yes, I know that means the risk is small, but the general public will over estimate it, and worry inappropriately. That seems to be a matter of education, not technology, though...

pdkl95 11y ago

Then "modern cars" can never be considered safe, and whomever the professional engineers are that signed off on that design have some explaining to do. "market forces" or "following my boss's orders" are not valid excuses; a professional engineer has a duty to ignore such things when considering safety. I suspect whole auto industry needs to re-learn (if they ever learned in the first place) the lesson of the Therac-25 and what "fail safe" means. Some dangerous situations should not be possible. Unfortunately, I suspect the auto industry will choose to learn those lessons the hard way. When people die from someone messing with their steering or brakes remotely, I hope whomever signed off the idea of mixing remote signalling with critical systems is found personally liable for manslaughter.

abduhl 11y ago
Does the software industry even have a requirement for professional licensure? If not, then there is no "professional engineer" that signed off on the design and there is no regulatory liability and hence no questions to answer by the engineer. This is one of big problems with the software industry nowadays. It has a role to play in nearly every major industry but does not have the same regulatory hoops to jump through to get into that industry. In this case, I am sure multiple mechanical and electrical licensed professional engineers had to stamp all of the physical components that make up the vehicle but I would be very surprised if any software was ever signed off on by a licensed professional engineer explicitly (there is a case to be made for implied acceptance by the engineer of record for the system that the software runs on but I think it is weak).
- mmagin 11y ago
  At least in the US, it is entirely plausible that many of the electrical engineers working in a large company on such a product are not licensed professional engineers.
maxerickson 11y ago
There are no cars on the road that have brake lines that are tamper proof, so I'm not sure you are setting the bar at the correct level. It will be interesting to watch the ongoing situation with Chrysler: http://www.wired.com/2015/08/chrysler-harman-hit-class-action-complaint-jeep-hack/ http://www.wired.com/2015/08/chrysler-harman-hit-class-actio... If the class action goes forward there will be a legal examination of whether a security flaw that allows remote tampering is a safety defect or not (of course it is, but I mean in the context of liability).