Live data from Hacker News

Hackers Remotely Attack a Jeep on the Highway

wired.com

51–60 of 640 posts

Re: Hackers Remotely Attack a Jeep on the Highway

#51
post #11

I think a basic idea should be: panic stops disconnect all wireless access. Which will probably result in lots of calls from people after they avoid hitting a dog. But still.

Disconnecting will not restore corrupted firmware. Once virus is there, disconnecting just prevents data transfer.

Re: Hackers Remotely Attack a Jeep on the Highway

#52

Some questions for the researchers, or anyone else who thinks this was okay: 1) Were public roadways and speeds of 70mph absolutely necessary to demo this? 2) What was the plan if the trucker approaching at 70mph hadn't seen the Jeep stalled early and had to swerve or panic stop, possibly crashing and injuring themselves or others? 3) Anyone notify the Missouri State Highway Patrol about this? They may be contacting…

You're not gonna make the news unless the media can spin up a headline that scares people People won't pay attention until they're scared People won't demand action if they're not paying attention Nothing will happened if people don't demand action. If nothing happens the status quo (vulnerable systems) will remain. Until some bad actor (I'm sure several nations states would love that capability) gets into onStar and…

[deleted]

Re: Hackers Remotely Attack a Jeep on the Highway

#53
post #46

Some questions for the researchers, or anyone else who thinks this was okay: 1) Were public roadways and speeds of 70mph absolutely necessary to demo this? 2) What was the plan if the trucker approaching at 70mph hadn't seen the Jeep stalled early and had to swerve or panic stop, possibly crashing and injuring themselves or others? 3) Anyone notify the Missouri State Highway Patrol about this? They may be contacting…

You called the cops on two security researchers and a journalist, because you disagreed with their methods and weren't sure what their plans were and what authorities they'd talked to? (And not just any cops, the cops in St. Louis, for bonus points.) Are we still on Hacker News, or is the transformation to Enablers of Traditional American Power Structure News complete?

There's plenty of safe ways to accomplish this kind of demonstration. The fact they choose to do so in a way that endangered the public is in fact criminal.

Being a security researcher or journalist doesn't give you a license to put the public in physical danger.

Re: Hackers Remotely Attack a Jeep on the Highway

#54
post #49

Earlier quoted context omitted.

No way a self driving car can rely on Internet access to "perform basic driving functions". Lag and connection failures would kill people. They might need Internet access for updates, in which case, there should be a physical switch that connects the net and disables the engine.

An air gap is hardly a solution for traffic information the route planner HAS to talk to the computer responsible for getting from A to B. In the same way that firewalls are no longer particularly relevant, air gaps appear to be flawed now too, the only way to solve any security issue is better code quality..

It's not perfect, but an air gap can help reduce the attack surface and interval.

Better code quality is important too, of course.

I agree with cameldrv that it's going to be a challenge.

Re: Hackers Remotely Attack a Jeep on the Highway

#55
post #11

I think a basic idea should be: panic stops disconnect all wireless access. Which will probably result in lots of calls from people after they avoid hitting a dog. But still.

Disconnecting will not restore corrupted firmware. Once virus is there, disconnecting just prevents data transfer.

Exactly. But at least you'd break the current control link and possibly/hopefully be able to stop and steer.

Maybe in addition to breaking a link on a panic stop, stopping and steering would be set to a non-commanded mode that relies less or not at all (maybe impossible with current design?) on software commands.

Re: Hackers Remotely Attack a Jeep on the Highway

#56

Some questions for the researchers, or anyone else who thinks this was okay: 1) Were public roadways and speeds of 70mph absolutely necessary to demo this? 2) What was the plan if the trucker approaching at 70mph hadn't seen the Jeep stalled early and had to swerve or panic stop, possibly crashing and injuring themselves or others? 3) Anyone notify the Missouri State Highway Patrol about this? They may be contacting…

You better have the Highway Patrol investigate every single person who doesn't maintain their car properly and takes it on the highway because they're causing far more risk than this demo came close to creating, IMHO.

Was it a stunt? Yes. Was it life threatening? Hardly. The real risk is the early 90s Civic with a torn up clutch and bald tires swerving between lanes.

Re: Hackers Remotely Attack a Jeep on the Highway

#57

So, it's becoming abundantly clear that vehicle companies (autos, jets...) have approximately zero knowledge how to hire software engineers. Presumably they're somewhat more successful hiring mechanical engineers because that's always been their "thing". It's all well and good for us to chuckle at the terrifying software/systems decisions being made by these teams, but how do we address the root of the problem? It's…

The fact that a dashboard system that controls your radio or AC has access to cut your transmission is also a hardware configuration issue. Accessories should be physically secured from ignition and drive train. The internet connected features of the car, in turn, should be severed from both of these. It should not be physically possible to turn on the wipers from the embedded processor that receives packets on the I…

That's why they test on this car. Because the CAN buses are all connected without "firewalls".

Re: Hackers Remotely Attack a Jeep on the Highway

#58
post #48

So if I'm understanding this correctly, the initial vulnerability is remote-exploitable and relies on a firmware patch. Why wouldn't the manufacturer use the same exploit to patch all affected vehicles rather than calling them in for service?

Presumably they lack permission to do such a thing.

The researchers only experimented on a car they owned/controlled.

Re: Hackers Remotely Attack a Jeep on the Highway

#59

So, it's becoming abundantly clear that vehicle companies (autos, jets...) have approximately zero knowledge how to hire software engineers. Presumably they're somewhat more successful hiring mechanical engineers because that's always been their "thing". It's all well and good for us to chuckle at the terrifying software/systems decisions being made by these teams, but how do we address the root of the problem? It's…

I think this also comes down to the curriculum and training that Computer Engineers receive during undergrad. Since the core courses touch embedded, hardware design, and software we're left with only the basics. Coming from the Detroit/Big 3 area a lot of my colleagues went off to Toyota (in ann arbor), GM, Chrysler, Ford, or one of their suppliers/contractors (Denzo et al.); and from what i've been told is that they do put a lot of effort into software, however it's focus is more on stability and function as opposed to security and portability.

This doesn't mean they're doing a good job though. Here's a link to where i previous discuss this: https://news.ycombinator.com/item?id=9801769

Re: Hackers Remotely Attack a Jeep on the Highway

#60
post #9

Earlier quoted context omitted.

Remote start I can see the reasoning for, but remote stop just seems to be asking for trouble.

The obvious but security-oblivious way to do this is to just connect the entertainment system that has the internet connection to one of the car's microcontroller busses. Even if it just needs to send a single command, it's easier than adding another pin and another wire to the appropriate microcontroller on the other end. The problem is that everything on these busses is completely trusted, and there's no authentica…

Encrypted and authenticated data on the bus won't happen anytime soon for cost reasons. Filtering the commands the controller can put on the bus seams reasonable, but would only be useful, if implemented on a second controller (probably won't happen, either).

I think the best approach is to secure the internet connection properly. Don't permit incoming connections at all and just permit a single outgoing TLS connection to the server of the manufacturer, define a very simple protocol and spend enough time to be sure the client is secure and validates everything.

Post reply on HN