Black Hat USA 2015: The full story of how that Jeep was hacked

Re:Black Hat USA 2015: The full story of how that Jeep was h... by forgottenpass on Friday August 14, 2015 @12:25AM (#10058615)

If the firmware is SECURITY CRITICAL then the only way to change it can be through physical presence, loading encrypted and and signed firmware

Physical access? So, hypothetically another car gets hacked, but this time there is no middleman in position to implement a mitigation like Sprint was in this case. How do you suggest a firmware rollout happens? Recalls? Mailing thumbdrives to end users?

Over the last week I've seen the infosec community warmer to the idea of OTA updates and all that baggage that entails compared to the alternative ways to update car firmware. You're posting pretty authoritatively though, if you've got some analysis that the rest of us don't, I'd love to hear it.

[ Parent | on HN ]

Re:Black Hat USA 2015: The full story of how that Jeep was h... by hueving on Friday August 14, 2015 @01:09AM (#10058729)

The basic idea is that this wouldn't have happened in the first place if it required physical access.

[ Parent | on HN ]

Re:Black Hat USA 2015: The full story of how that Jeep was h... by dlgeek on Friday August 14, 2015 @02:12AM (#10058867)

And if it was a buffer overflow that lead to an arbitrary RCE instead of a firmware-overwrite, and the fix was to upgrade the code to fix the buffer overflow?

[ Parent | on HN ]

Re:Black Hat USA 2015: The full story of how that Jeep was h... by klibertp on Friday August 14, 2015 @08:15AM (#10059713)

What buffer overflow? Obviously the firmware is formally proven correct and proven not to include any of those?

(I'm half joking here - I suspect that's not the case and won't be the case for a foreseeable future, but I'd be happy to learn I'm wrong here)

[ Parent | on HN ]