Hacker News Reader

Comment by Quarrelsome | Hacker News Reader

they do "over the air" updates? Of the software that powers the vehicle?

Isn't that an _exceptionally_ dangerous vector?

In what way? Sign updates, validate signature, and only apply when car is off and at home charging. Maybe some POST/rollback logic even possible. It's not much different than going to a dealer to get ECU flashed.

In the way that it suddenly becomes technically plausible to make a certain % of vehicles turn into oncoming traffic on a Monday morning.

Make every car on a particular road at a particular time, hit full speed and hit a particular target.

Cars are like crap missiles so making them potentially exploitable is a bit risky.

But even non OTA cars with lane assist and such have this same threat vector. If attacker compromise the vehicle code supply chain to introduce such a thing, whether it got loaded via OTA update or flashed by dealer when I took it in for service makes no major difference. If anything, it's more likely that OTA updates mean they can remediate REAL bugs that save lives across a vast majority of cars in record time (vs recalls and in person flashing).

over the air means automatic though. At least with dealer flashing, a poisoned chain has less impact because its slower and less broad. With a fully automated process you run the risk of it being a vector for terror attacks,

Sure the point that non-OTA (i.e. just 'software in cars') still permits more localised attacks (e.g. assassination) but OTA represents a huge honey pot of power that I would argue is an inherent danger.

I personally feel like there's a whole bunch of stuff we really shouldn't be automating and specifically attaching to auto-update until we've got a better handle on zero days as an industry.

Maybe I'm too optimistic but I think the net risk is reduced with more readily access to updates. The terrorism line just really doesn't strike me as a likely threat. Regular bug fixes and improvements to daily use are likely to save far more lives. Besides, there should be so many audit/checkpoints in front of the release chain, that scenario just seems implausible (but I do conceed that stuff can also fail or be bypassed- let's hope Tesla and other manufacturers have decent IS engineering)

The update process would definitely be atomic -- you either update successfully or stay where you are. Different ways of doing this -- something like OSTree would be my first choice for automotive otherwise you're sending the full image OTA and you need enough flash for a full A/B.

It's very dangerous, but it used to be considered extremely dangerous to update anything in production until the likes of Google started doing it nearly two decades ago. The secret sauce is to use DevOps: automated testing and so on. But it's a culture the auto industry does not have. They can't do it for the same reason most banks for example can't do it (yet), and it's taking them years to get there.

I guess that's why it is not so easy. Volkswagen is struggling https://www.autoblog.com/2019/12/27/vw-id3-ev-software-issue...

It depends on how they do it. It very well could be :)

yep

Not if done correctly and you take security seriously. Most auto manufacturers outsource software development and engineering.

Tesla also offer pretty good bounties every year on PWN2OWN:

https://www.zdnet.com/article/tesla-car-hacked-at-pwn2own-co...

https://www.thezdi.com/blog/2020/1/8/pwn2own-returns-to-vanc...

Ye but transitioning from impossible to plausible carries an inherent risk. If that honey pot is attractive enough then it will gain more attention and increase the chances of zero days.

The potential impact of an exploited zero day in this context has the potential to be immense and that's the risk that troubles me.

Reply on news.ycombinator.com