Hacker News Reader

Comment by baseballmerpeak | Hacker News Reader

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.

View on HN

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.

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).

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.

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-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).

are you arguing the difference in the ease with which digital information can be altered compared to physical reality is a negligible difference?

I'm pointing out that shipping imperfect software has not yet been determined to be negligence.

I pretty much expect that automakers will quickly start shipping systems with effective segregation (the cost pretty clearly doesn't outweigh the PR downside), so the interesting question really is whether the cars on the road today represent negligence or not.

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

I hope they get this sorted before self driving cars... (50 bitcoin in 20 minutes or your car takes a drive off the pier...)

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).

> 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...

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.

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.

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.

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.

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).

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.

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.

Some controllers already do some similar things, more like shared secrets though. It's common in the brakes. There is some sequence of commands that have to be sent first otherwise later commands will be ignored. The problem is that 1) you can wire in a scope and watch 2) just try every possibility or 3) use the diagnostic/test messages instead that accomplish the same without all of that.

There are devices like this in use, i worked with automotive and we used a device like this to attach certified third party factory installed add-ons, they also translated vendor specific quirks in the protocol so that both sides would understand each other better. In essence the third party was kindof trusted but to be on the safe side we firewalled them to only allow a list of white listed commands, more like an API. Not having this kind of barrier for internet attached devices is inexcusable.

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.

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.

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.

Linked but not linked to the internet by default :)

Reply on news.ycombinator.com