If I recall correctly the part of the system this is running on is independant from anything important and only does media controls. It also speaks to the rest of the car over a network interface.

But still not quite for the faint of heart.

There have actually been a ton of examples over the years of researchers hacking into car systems wirelessly, some of which used the media system as the attack vector.

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.

>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.

I wouldn't be so sure.

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) 

[1]: https://www.blackhat.com/docs/asia-15/materials/asia-15-Even...

[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...

Sensible cars have a device bridging high and low security networks, forwarding data from one to the other, specifically so that a misbehaving media device or light system can't clobber the brakes or ECU. No idea if the Tesla does this or not, but it's a fairly standard approach.

Yes, it has a gateway between the high level stuff and the low level stuff. It's fairly secure too. You can't just make calls to the can bus all willy-nilly either.

> You can't just make calls to the can bus all willy-nilly either.

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.

It's a completely different computer—compare it to your typical web browser/web server model. The media computer can request display the battery information (the browser can get a list of products) but it cannot hit the accelerator (the browser cannot read other users' personal information). Even if you have root on the media center (your laptop), that doesn't make it so you can run any and all commands on the computer that regulates steering and acceleration (the web server).

there is a gateway between the media center canbus and the critical canbus. the gateway buffers all the data from the critical canbus and rate limits any requests for data which isn't broadcast regularly on the critical canbus.

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

though wasn't the chrysler attack through one of these gateways?

The chrysler was a completely different system, but it was indeed infecting the car from the radio / entertainment system. The tesla is completely different from that. They have one entire computer system that runs the "entertainment console". You can even reboot it while you are driving and nothing happens (this is by design of course). The driving controls are totally separated. The only thing you notice when you reboot that console if that the radio goes off, the display goes black during the reboot (10 seconds). Then it comes back and all is well. Press both turning cylinder controls on the steering wheel for a few seconds to start the reboot. They designed it very well. That doesn't mean it is perfect, but they have approached security correctly as far as I can tell from outside. They pay for exploits too - see https://bugcrowd.com/tesla. They have hired security researchers to work on their system and attack it.

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.

But it might fubar your warranty...

"Your honor, we were not responsible for that AutoPilot crash because the driver did an unauthorized modification of the car's software!"

This should be handled like we handle replacing the breaks in your car if you do it yourself.

How is that handled?

This is part of the Magnuson Moss Warranty Act: https://en.wikipedia.org/wiki/Magnuson%E2%80%93Moss_Warranty...

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.

While I appreciate the sentiment there, that seems like its ripe for protracted litigation (which will never benefit the consumer).

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.

Not sure why you are being downvoted, you present a valid point.

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, but if you decide to tint your windows it doesn't somehow magically invalidate your powertrain warranty.

Which is worse, proprietary closed system from car manufacturer or OSS system.

There's as many pros on one side as cons on the other.

False dichotomy - I think it should be similar to Kerckhoffs's principle in the long run. OSS yes, but it's signed and audited when it's able to run. Maybe like an open source version of microcode updates for CPUs. You could file a pull request because you spotted a bug but you can't fuck around your car (bad, but not so bad) and other cars (very bad).

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 :)

Does the fact that most of the code in your car is autogenerated from tools like Modelica change your view on how likely this can/should be opened?

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?

How exactly is it separated?

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.

It's incredibly complicated, but pretty secure. The CAN bus is isolated from the network. I have root access on the CID and the IC (both separate tegra systems). You can even reboot the CID while you're driving and you only lose media and air conditioning and such. Accessing the CAN bus requires going through a pretty secure gateway system, so you can only basically make requests. Even then, I haven't even really looked into that area much.

It's a chroot'd environment. Yeah, you could theoretically crash the underlying kernel, but doing so would probably be pretty difficult. You'd have to give that environment access to things that can crash the kernel on purpose.

exactly WHY I'll wait for it to mature first, if at all...

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

Yep. Jeep Cherokee was hacked by connecting to multimedia system which supposed to be separate from driving system, yet our wasn't a problem.

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.

If you read, he's running in a chroot within the TelsaOS (which I'm guessing controls a lot of the sensor in/outs for displays and can't really be removed).

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.

she is running in a chroot

I'm sure everyone is aware of the fact that all kinds of potential quality-of-service crosstalk/resource utilization issues are not prevented by a chroot.

I wonder what happens when you get into a bad crash, somebody decides to sue, and it comes out that your car was running modified software. Would you be exposing yourself to any liability?

Massad Ayoob recommends against [0] using a defensive firearm with, say, a modified trigger due to potential liability. [1] This situation seems similar.

[0]: http://www.thetruthaboutguns.com/2011/01/brad-kozak/the-mass...

[1]: http://www.royblack.com/files/Alvarez.pdf

I can imagine a few ways that you could.

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.

Most in-dash sat/nav units aren't allowed to play any video in most states. You can bypass/disable it, but that can run you into liability issues.

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.

This always comes up in these threads, but I don't understand how it would be any different from millions of cars running around with modified engines, suspensions, brakes, non-OEM tires and wheels. If it can be shown that your modification contributed to the accident, then liability will be apportioned accordingly. Usually it can't.

But software is much more complicated. If I put aftermarket suspension in, it's pretty unlikely that it will significantly screw up my brakes. But with software, it's a lot harder to say what affects what, especially considering how many cars have a single computer that handles both critical and non-critical tasks. A media player mod could very well screw up the brakes by hogging system resources or crashing the computer. If my insurance refuses to pay out after a crash on account of that, do I have to prove my mods to be safe?

NB: I have almost no idea how liability and insurance works in the US.

He needs to wire the "deploy airbags" trigger to also do "reset software to factory default.".

Aren't you already liable for all damage in an at fault accident? If you modified it yourself, I'm not sure there's any blame that can be shifted around.

If whoever you hit's lawyer manages to make a case that the accident was worse as a result of your modifications, you might have a problem.

Not before tesla disables the car.:) from what I read, any kind of hacking can get your vehicle disabled.

I guess it's like if you replace the breaks yourself.

This is exactly how I think of it. No one questions people doing mechanical work on their car, but touch the software and you get crucified.

People still don' (want to) understand software.

It's just a chroot. Thats far less dangerous than completely reflashing it etc

So what happens when your app hits an infinite loop and locks the CPU? Or trashes some memory it shouldn't?

Does autopilot still work? Do the airbags still deploy? Does the brake still work?

It is an interesting question. A while a go, 2 guys made a presentation at DEFCON with a presentation about their findings on hacking a Tesla Model S.

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

While it is very reassuring that the car is able, the speedpoint chosen by Tesla – 50kmph — is not. I'd rather a car not be remote-controllable at anything more than a slow crawl, and 50kmph is quite capable of making such a heavy car dangerous.

I'm not sure what are the exact conditions for the Tesla OS to be overridden by other internal systems, 50 km/h was just a placeholder value for "lower speeds".

It should. In a world where people routinely talk/text/drink and drive I don't think we should expect 100% from electric or self-driving cars.

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.

Preemptive multitasking means that infinite loops in userland software do not lock the CPU. Everything that anyone would cal an app is run on a system that does preemptive multitasking, so it is not a problem. Presumably, the dashboard console computer is separate from the many other computers in the car for reliability purposes. If it is not, Telsa Motors would have really messed up.

I have never driven while running any of my stuff. Also, this is the CID, it doesn't control those things. You can even reboot the CID while you're driving.

The safety-critical stuff is not running on that computer. So the brakes still work, and the airbags deploy, for sure. I'd be very surprised if the autopilot is on there.

Again, this entertainment system that she hacked is completely separate from the driving system. You can literally reboot it while you are driving down the road. The screen goes black during reboot, the radio goes off, then it comes back in 10 seconds or so. I think maybe in the 4 years I've owned it once or twice it rebooted itself.

The one auto manufacturer that I was working for had hardware safety overrides for any software controlled remote operations.

For example: Remote door unlock command issued by the mobile phone app will not work if the car is moving.

I'd hope so, since apparently the computer that's being hacked here occasionally crashes and restarts in normal operation with the official unmodified Tesla firmware.

You know some people mod the engine on their car, right? Or swap the transmission? Changing the software is hardly the most significant modification owners do to their cars, at least for non-self-driving cars ;)

nah. people have been modding throttle bodies and adding short shift to their cars for ages.

it is the same thing.

OT but what was the deal with the Toyota thing? I read something about this on HN the other day and as far as I can see they were unable to reproduce the bug https://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle...

Would love to hear more about it from anyone who has more information.

The code was (probably typical) contractor spaghetti code, with plenty of potential bugs. But, no conclusive reproduction steps were ever found - much less any that would cause it to continue acceleration with the brakes on, transmission disengaged, or key off.

This was my favorite read,

https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_...

Thanks!

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.

Since they are limited to 5 engines per season[0], they were probably very worried that the fault could lead to the loss of an engine. When I did racing, for even the most minor of faults/errors/"that's odd", large amounts of effort were put into correcting the fault if it was on the list of "If this broke, we lost".

[0]: http://www.formula1.com/content/fom-website/en/championship/...

edit: grammar fix

> ...we can hardly trust manufacturers to develop robust automotive software on their own...

All the more reason to root the device.