The real fix will require much more intervention than just a firmware flash at the garage.
We'll see at Def Con how much Chrysler really screwed up.
The real fix will require much more intervention than just a firmware flash at the garage.
We'll see at Def Con how much Chrysler really screwed up.
It's the only one available to them. They can't just refit all existing cars with a new design on a short timeline. Hardware has permanence.
With that in mind, how would you fix the issue for existing vehicles?
We recommend layered security to protect people's cat pictures – doesn't it seem like a good idea for something which could literally result in casualties?
If they were yanking the cellular connection that'd be pretty good... If they're just patching one or two obvious holes it'll likely be broken again by Blackhat.
But:
https://twitter.com/0xcharlie/status/624608184485851136
So the vehicle connection is not as visible as it used to be.
But that's the least useful way to protect us. Literally. If the vehicles remained visible they'd have to fix the bugs - this way they'll simply pretend they did.
Analogy: is it worth the time making a pick-proof lock for the front door when someone can just break a window?
(I'm not saying we should let car manufacturers off the hook, just offering a perspective on the realism of the threat.)
Attribution. Mechanical attacks are easier to attribute than something that can be done from across the world over the Internet.
>Analogy: is it worth the time making a pick-proof lock for the front door when someone can just break a window?
Yes, because not everyone can throw a rock from their house to yours, be nearly everyone can be connected to the internet.
The problem is access to the CAN bus is necessary to change various vehicle settings from the infotainment system. I know for a fact that changing the door lock settings in my car requires the infotainment system to access the CAN bus to apply settings to that system.
This is not an unsolvable problem; this is basic software engineering. Processes should be isolated from each other. I imagine everything in the infotainment system effectively runs as "root" because they consider the whole thing a singular black box.
Yes, the info system needs SOME access to the CAN network. But it shouldn't be unrestricted access. Instead the info system should be treated as "untrusted" and only specific things should be permissible over a well documented set of APIs.
I'd almost be tempted to say that while the car is moving, ALL access to the CAN network should be disabled. Since let's name some things the info system needs on the CAN network:
- Reconfigure car (e.g. daylight running lights, auto-locking door, etc).
- Start car remotely.
- Set AC remotely.
- Diagnostics.
The only one on that list which MIGHT be useful to have while the car is in motion is diagnostics. And that could be delivered via a read only interface.
Totally doable, but it is unbelievable to me the lack of forethought in things like this.
I think that's a good idea, but I think it would be better if it was a small hardware firewall than a program in the infotainment system.
I would think something like that could even be entirely formally verified.
So we're in complete agreement.
Other cars have climate controls built into the info unit.
Then, there are cars like Tesla where nearly everything comes from the info unit...
It's not really about RO v RW, CAN is about sending commands. The head unit could say, it's the brakes, so that has to be protected against.
When there is not a physical layer doing that protection (separate bus, a filter, and so on) there are two other layers. One is the thing sending can reject it from going out, but that takes resources that might not be there. The other the receiver does some sanity checking on it, like "you want me to go in P but I'm going at 65, yeah I don't think so" to even it's gotten common place for messages involving the brakes include a shared code back and forth.
Really I think this boils down to there are untrusted channels (wifi, cellular, DAB) that should be locked down better. I mean the DAB thing, likely it's a buffer over flow in the head unit. Even if that has a cpu that is running FW that is making sure the CAN messages it is sending are sane, the exploit just makes it stop doing that. There's such a pressure to save cost and so many OEMs involved that ease of integration motivates the rest.
Yeah it sucks, but it is what it is.
But wouldn't those likely be one-way commands TO the infotainment system? They would still work even if it was receive only.
Basically there is no notion of to or from really. When you push the vol+ button on the steering wheel there is a controller that sends a message trying over and over again until there is no collision. That message has an ID in it early on. In this case it will be like I dunno $412 okay. That means audio controls or something. A bit later is some length and then the data, say the data is $C.
The infotainment unit is listening to everything just as the controller for the steering wheel controls is and everything else on the bus (it has to, because of how collision detection works). When the controller in the steering wheel sees that $412 ... $C it goes, well isn't that nice, me or someone else sent the vol+ message out finally, cool, I'll stop sending that now. When the radio sees that message with an ID of $412 it goes, oh that's an audio control message command, I should pay attention to that. Then it looks at the length and data and sees $C. It goes oh that means someone pressed vol+, I'll make it louder.
But here's the thing, there might be a knob too for volume and there really is just one board doing the infotainment. It's not like the old days where it's a potentiometer, it's not even wired directly into the board that handles infotainment. All the IO pins that board has are already used-up handling the screen, CAN bus, and other things. When you twist it, it also sends the same $412 ... $C over CAN from it's controller! The radio did not know what sent it, and that's by design in CAN bus.
There might be mobile phone integration, it can do CAN too, say also a $412 with with a different payload (and possibly length) that might mute on call. Also there may be a touch screen, but that will not do a thing over CAN if you press the vol+ there, just do it's normal IO from screen to SoC on the board.
Am I doing a better job of explaining? The take away is lots of things can send the same message and lots of things might be interested in that message and that is how it is intended. To some extent you can mitigate this in hardware. You can make long runs or some shorter star shaped topologies as long as you get the termination right. For the star shaped topologies you can stick gateways in there. The controllers can be setup to filter on certain conditions and the bus is the limit for filtering if you are using a programmable part. What I mean by bus is the limit is things like there is no notion of to and from.
That's what you get in CAN bus cause that's how it works. You can thank Bosch for that.
CAN is great for its purpose, but handling untrusted actors is not part of that purpose.
What should happen is a non-CAN hardware gateway that only passes valid commands to CAN buses.
It seems like a good design in a very noisy environment and it does allow the car manufacturer to easily add in new controls ( volume up for example ) in different locations that do the same thing.
"Yeah it sucks, but it is what it is."
This attitude might work with some other things, but the automotive industry will have to deal with security in a reasonable fashion. This is potentially life-and-death stuff and consumers actually have choice here. Not everyone understands the full implication of someone tracking their cellphone or hacking their email, but everyone can imagine what will happen if your car will get out of your control.
I've been trying to describe two things. One, the way that CAN bus operates, so some of the technical solutions people have been making just are impossible. People should imagine that CAN bus is something like RS-485 or the old systems that had some mix of ISA and PCI, not like switched ethernet. The second item is a bit of how these things happen in business world, for good or bad, not that I agree with it or anything.
That's vitally important to understand. The systems are mingled but they don't have to be and in fact shouldn't be.
Also, not all isolation is the same. Consider the scope of isolation between multiple sandboxed apps (some accessing the raw internet) on a single computer and two separate computers connected via a specialized protocol-aware data diode.
There is little genuine need to send commands from low-importance networks to high-importance networks. Yes, you would have to live without single uber-control touchscreen, but it's not really that big of a limitation: you simply need separate controls for low-importance and high-importance things.
Last car I had (Kia Forte) was actually very pleasurable... they had a very helpful digital display but all the adjustment could be done w/real buttons.
The direct control interfaces in a car that tend to be very well designed and implemented are the basic movement controls like the steering wheel and pedals. These are distinctive and immediately recognisable. They work predictably and after proper driver training they become very intuitive. Drivers in an emergency can often still manage to swerve or brake to avoid a collision, and that is the level of user friendliness you want when you're in control of multiple tonnes of fast-moving death machine.
Other parts of the interface that modern cars tend to do very well are all the subtle behaviours behind those controls: the power steering that adjusts so it "feels right" at any speed, the independent driving and braking of different wheels so the simple pedal controls don't unnecessarily spin the wheels if you try to move off with too much gas but do retain control without skidding unnecessarily if you brake and steer at the same time in an emergency.
And of course there are a raft of safety systems in modern cars, some fully automatic, but some giving subtle cues to the driver to help them predict and hopefully avoid dangerous situations earlier.
But these so-called infotainment systems, and radios, and communications systems, and satnavs, and fancy environmental controls... Most of these are just awful, and sneering at them is entirely fair and justified right now, so separating them from the essential controls that keep the vehicle operating properly and safely should really be no problem at all.
It's not just security - you can't have bugs in one system causing other systems to go down. You can't tolerate a bug in the radio causing the car to crash (didn't anyone learn anything from the demise of the Death Star?)
The Fukushima disaster and the Deepwater Horizon disaster, from what I read about them, all suffered from easily preventable "zipper effect" of cascading failures.
Every industry apparently has to relearn the hard way what the aviation industry learned decades ago (and what the Navy learned even earlier).
It could be it's own CAN bus completely separated but you probably also have the CC on the wheel too. So do you put the CC on the same one? But wait, there's the SRS there too, oh man that plays ball with the self diagnostics.
Hmm looks like we need a high priority CAN in the wheel, might as well use it for everything.
That's how it goes...
It's the infosystem that shouldn't be able to broadcast on that bus. There should be a very limited set of messages that will be accepted from it and there should be a dedicated circuit that drops everything else.
So one reason the infotainment might want to send commands is to that station/song information appears in the instrument cluster.
Now I agree it would be really smart if there was another module sitting between the the radio and the IPC with two sides and it filters both ways. Also that gateway has logic like, I have power but it's been less than a minute, this packet has the right code, sure I will let this reflash happen. In fact such devices exist (except they are more trusting).
The thing is though that the radio tends to have the most impressive CPU of all in the car, so there is pressure to add that in there (I mean there was one manufacturer that had tried to merge BCM, TCM, telematics, and DIC all into the head unit with a roughly 400MHz cpu, so that gives oyu an idea), logic like 'yeah maybe, we won't be sending that in fact.' But once it is hacked, all bets are off, it can even DOS the bus. The other aspect is you just want they crap from Delco to work with the stuff from TRW and the gateway is getting in the way and yo don't want to expend the resources to figure-out why.
When it was all a wired network, it did not really matter so much.
I get that. And if it did, the attack would by spoofing that.
Which is why the solution needs to filter what goes onto the bus - at the only point the source is known.
> When it was all a wired network, it did not really matter so much.
Well, consider if I told you there was a way to "cut the brakes" (at a future date, when the car is at speed, etc) on any car you've been in, without any tools needed or evidence left. Untraceable murder.
It's only the scope of the current attack that makes that look minor.
So often though a designer will say "We really want to help people who call in for roadside assistance, we just want to read the CAN bus, we don't need to write it." And some complex function will be created that only "reads" but then a overflow attack or some other exploit lets arbitrary code get run and since its possible to write code with a write function your security is toast.
So what actually will happen (I hope) is that a bunch of things will no longer be possible from the infotainment system because that system doesn't have access to the CAN bus at all. And any UI that does have access to the CAN bus won't have any wireless access to it at all. Which will make some car features, less featurefull.
I definitely agree though they need to take this to the level that's usually seen in avionics with a read only gap between the third entertainment system bus. Without that you really can't hope to secure it. The only real problem I can see is how would you let the roadside assistance stuff unlock the doors? Maybe an authenticated write only to the low speed bus that you don't get to control the message, just "unlock all doors".
http://www.lakecountrynow.com/opinion/blogs/communityblogs/1...
After more investigation they ended up suspecting a different failure mode, but it speaks to the danger of even pedestrian functionality. Most people are shit drivers who are unsafe to be around in the best of times, "minor" things like stereo control, windshield washing, etc are certainly enough to distract them let alone being physically moved out of the reach of the controls. Particularly in combination, let alone in rush hour traffic or bad weather.
No, it's the only easy option they have.
Take all the vulnerable vehicles off the road. That's another option they have.
> How would you fix the issue for existing vehicles?
Have dealers yank the cellular connection in every vehicle and refund the customers something for removing a feature the product sold with.
Nothing else will fix it in a short timeline.
That automobiles are recalled for reasons other than hardware replacement is a recent phenomenon.
However a software patch would keep Def Con busy while replacement hardware is developed.
Sure, but how often are they doing major surgery vs. replacing a part / doing a patch? It sounds to me like properly fixing this issue would be a fairly sizable undertaking.
We need to communicate that this isn't a decent half-measure, this is specifically a worthless measure intended to keep vulnerable cars on the street where they can kill people because a real fix is seen as being too expensive.
You are absolutely correct. Unfortunately, so is "jacquesm":
> > They have to be seen to do something to counter all the bad press.
To me, Fiat Chrysler is doing classic PR damage control that the automotive industry knows far too well. It wouldn't surprise me to find out that Fiat Chrysler has threat analysis reports regarding this and other vulnerabilities within their organization.
Sadly, this is not uncommon in the automotive industry[1]:
GM has been heavily critiqued after the
company admitted that engineers were aware of
the issues that caused this recall as early as
2004. Yet it took nearly 10 years later for GM
to finally issue a recall ...
1 - http://www.bcoonlaw.com/general_motors_recall_lawsuitThat thing here is a big fucking warning to all other car manufactures for the future.
http://www.wired.com/2015/07/jeep-hack-chrysler-recalls-1-4m...
> Chrysler says it’s also taken steps to block the digital attack Miller and Valasek demonstrated with “network-level security measures”—presumably security tools that detect and block the attack on Sprint’s network, the cellular carrier that connect Chrysler’s vehicles to the Internet.
Oh great, they'll install an antivirus and think they've fixed the problem.
This is a super strange thing to say after your first quote. They've blocked it on the cell network AND are sending out updates to car owners.
So how you ignore your own first quote to criticise them for "only" blocking it at the network level is bizarre, it is like you didn't read your own post...
Any network fix is useless smoke and mirrors.
So, if I'm in someone's Fiat Chryslermobile, and they're pumping gas, I can flash the vehicle's firmware from the passenger seat?
This seems a lot easier than rooting it over the air.
Regardless it's the only and correct decision they can make at this time. It's honestly not terrible at all. What would be terrible, and valid of the comment "a terrible decision" would be doing nothing at all.
We all acknowledged the issue is architecture, and that can't be fixed by flashing firmware.
Ignoring direct violence? DoS PSAPs so small things like reporting burglaries or helping heart-attack patients fails. Or shit, have you seen the cabling at many datacentres? Take a few of those out and the US Internet would be off for what, weeks? (And that one you can even do remotely.)
My point is that you cannot harden the entire US infrastructure. Saying this car issue "has terrorism implications" is either a tautology or fearmongering.