Hacker News Reader

Comment by mkr-hn | Hacker News Reader

It's a complex attack vector for a simple problem. If you have enough access to tamper with the software, why not just remove the cap from the brake fluid reservoir? It's faster than figuring out how to access the PCM [1] (to tinker with the throttle code) and less likely to fail.

And it would be catastrophically poor planning on the part of car designers to make car firmware remotely modifiable. We're not talking about general purpose computers here.

[1] http://en.wikipedia.org/wiki/Engine_control_unit

View on HN

It turns out cars are catastrophically poorly planned then. Check out http://www.computer.org/portal/web/csdl/doi/10.1109/SP.2010.... -- they found they could cause the engine to stop, or the brakes to come on individual wheels by hacking the internal car network (Canbus).

It's a vector, however, that needs no physical access to the car. It can be launched remotely from another country.

Who would have thought a centrifuge could be attacked in this way?

> It's a vector, however, that needs no physical access to the car.

Are you sure about that? I can't imagine they'd put these autonomous driving systems on the network... Didn't Stuxnet itself require at least physical access by proxy in that it was propagated through USB drives being physically used in the victim's systems?

Many cars have Bluetooth support.

All it takes from there is the engineer putting the powertrain bus/ECU on the same network with the Bluetooth adapter.

As I posted below, my Saab's engine control unit can be reprogrammed by splicing a few wires onto the CD harness. That means the audio network can at least access the ECU. I don't have a Bluetooth adapter on my car, but if I did, I'd wager it can access the audio network...

Good point. I'd hope the regulatory system will require that systems that can make the car move be totally isolated from any other systems, but who knows.

...Assuming it works as advertised, there are some handy features, including the ability to remotely lock and unlock the car, fire up the climate control, see how much gas is in the tank, look up in Google Maps where you left you car, and check if the lights are on.

http://www.reghardware.com/2011/07/06/review_cars_volvo_s60_...

Nissan Leaf[1], TomTom Live Traffic, GOOG(maps)...

[1] http://seattlewireless.net/~casey/?p=97

> It's a complex attack vector for a simple problem. If you have enough access to tamper with the software, why not just remove the cap from the brake fluid reservoir?

Actually, depending how integrated are the subsystems in the car, one could just create a specially crafted MP3 and leave a CD or USB stick in the victim's car. This MP3 would work like the JailBrakeMe pdf and essentially put the victim's computer in the hands of the attacker. It's been done by security researchers, but I can't find the reference now.

Except that the target may discover the leak, and the lack of ability to brake; newer cars will warn when the fluid pressure is low. Switching the car to first gear to slow could get the driver out of immediate danger. I think the emergency brake uses a wire that is directly connected to the brakes.

However, I do presume that the victim is paying attention to their vehicle and not in a sudden emergency condition.

> And it would be catastrophically poor planning on the part of car designers

Why? I'm sure they don't like recalling their cars every couple of months to fix a bug, and customers don't either.

Car firmware developers know the exact hardware, needs, and uses in every case. Think about where most bugs come from: people doing things the developer didn't expect. Cars don't have many inputs, and those few inputs don't have many possible values.

Reply on news.ycombinator.com