This is a terrible decision. On such a short timescale, they'll only be able to fix the particular bug in their infotainment system. The real problem as everyone has pointed out is that the car control and infotainment should not share channels. There should be a physical gap between them and if really necessary a very tightly controlled message bridge.
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 infotainment system should never have access to the CAN[1] network in the first place... ever. At most, they could have a very simple listener on the can network that could send data (one way only) to the infotainment device via a different channel of sorts. Mixing the two is asking for issues such as just this to happen.
> The infotainment system should never have access to the CAN[1] network in the first place... ever.
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.
Cars can have three separate networks for infotainment (radio, navigation, etc), body controls (seats, lighting, locks) and mission-critical stuff (steering, breaks, engine). Some of them actually do.
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.
I rent cars often, I really dislike the ones w/a giant touch-screen on the front and nothing else. To me it's a gimmick and totally unsafe, since I have to look at the screen to do anything on it, sometimes repeatedly if it didn't recognize my touches. So they often end up duplicating all controls on the steering wheel, how is that 'good design'?
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 parts of car UIs we're talking about are mostly awful anyway, and on several different levels. They have basic design flaws like using naff graphics, which neither look good nor supply information more effectively than simpler alternatives, and using non-tactile controls like touchscreens or fully circular rotating dials. Hopefully by now everyone knows the dangers introduced by most of the mobile communications systems in modern cars.
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.
I agree with both you and the person above. I think the missing word we're looking for is: "unrestricted" (as in unrestricted access should not be permitted).
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.
Steering wheel audio controls are common and useful in motion.
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.
What you're describing sounds like a firewall for CAN. It's a complex solution that will inevitably be insecure.
"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.
FWIW some companies handle this better than others. In this case FCA took the Uconnect code from a different division and integrated it. People make mistakes, something was listening and passing on more than it should in that system, now it is fixed. I'm really impressed with the researchers work.
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.
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.
Thanks. I bet like most things in this world, this design grew organicly.
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.
And thank you for the polite response, I appreciate it. One further nice thing about CAN, because of how it works electrically (basically logically zero always wins) it is trivial to have messages (and message types, I only described the most common data type) of different priorities. So a low numbered ID always wins. That also allows a trivial DOS, oa bit blaster that repeats something like 000000100001...CRC... might not even trigger an error detection. It really is quite a nifty thing, amazing it works so well too.
Thanks for the detailed explanation. So it's a completely trusted bus architecture. And what you absolutely shouldn't do in that scenario is expose it directly to Wi-Fi and 3G, which is exactly what it sounds like they did. I hope that this exploit gets manufacturers treating this issue with the importance it deserves, but my cynicism says they'll largely ignore it until people die.
That looks like an absurd amount of complexity/overengineering just to save some wire. I suppose "put everything on one bus" could be turning into some sort of anti-pattern.
Consider how much wire would be required to route every button directly. There would be tens of pounds of extra metal, plus impossible bundles of hundreds of wires to route around the car.
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 was a lot of wire saved. A 1985 Mercedes has a chassis wire harness that is almost three inches in diameter at its thickest point. They wouldn't have done it if it hadn't been a bargain.
Porsche and Audi (and likely others) have secondary nav displays [upcoming turn and distance] that originates in the info unit and is displayed somewhere on the dash.
Other cars have climate controls built into the info unit.
Then, there are cars like Tesla where nearly everything comes from the info unit...
The original 'researcher' (because they did something so horrendously unsafe on public roads) mentioned that there are at least 2 car manufacturers who have devices on the CAN bus to watch traffic and detect when a device is issuing commands that it shouldn't be so the tampering can be detected (and assumedly shut the infotainment system off).
You can't control for other bad drivers' reactions to your vehicle becoming an obstacle on the highway. Swerve and change lanes? Sure, in an ideal world that always happens. In the real world, accidents can happen instead.
Let's say there is a low chance of death from doing this: 1:10:000.
Arguably that's about the same as sending someone to jail for 1:10,000th their life. Which is about 2 and 1/2 days which is not ‘horrific’. Still, I would hope sending a random person to prison for a few days to stage a story seems unacceptable.
On the other hand vaccinations are both lower risks and a higher benefit so it’s not really comparable.
You are unqualified to determine the level of risk that was imposed on the other drivers. You have no idea how many zeros to add or remove to how likely an accident was to result from this. I'm not sure there exists a person that could give an accurate representation beyond generalities, so please don't present yourself as this person.
The point, the only point, really, that people have with their actions is that they endangered other people on purpose and without their consent. I wouldn't defend someone weaving between cars in traffic and leaving inches between bumpers doing so (I'm sure many of us have seen this) for the exact same reason. There are far too many variables to accurately account for, so they are raising the risk to all the people around them. Even an expert driver can't claim to know how every other driver on the road will react.
That the researchers did this for what I'm sure most of us believe is a good reason is irrelevant, given there were alternatives. They made a judgement call, and now we are all upset at their poor judgement.
> Add four or five more zeros and you'll be in the ballpark.
So the 1:10,000 should be between 1:100,000,000 and 1:1,000,000,000? You're saying that, on average, between one hundred million and one billion vehicles would need to pass a stopped vehicle on the highway before causing an accident? Sorry, but if your arguments previously strained credibility this takes the cake.
That a mild slowing of the vehicle ahead would cause a fatal collision that wouldn't have happened otherwise, yeah.
This called for the same reaction as would adjusting speed to match any car that took their foot off the accelerator; the Jeep didn't even brake! Driving is a continual process of these slow interactions and that's not the part that causes accidents, and considering relative speed they would also tend to be non-fatal accidents if they did happen.
That just makes it more dangerous - there was no brake light to clearly indicate the car was slowing. Since we know drivers rear-end cars quite often we know the risk of accident was increased here.
Increasing the risk of accident is not acceptable unless all participants have given informed consent (they didn't).
That's fine if you're behind the vehicle right when it starts slowing down. I agree with you that a fatal accident is highly improbable there. But it didn't just slow down a bit and then resume speed. If you watched the video you saw that the vehicle came to a complete stop. The vehicles that saw it mildly slowing down have already driven by, leaving only incoming vehicles going 70mph unprepared for a vehicle ahead at a total standstill. Hopefully those unprepared drivers are sufficiently conscious, alert, and otherwise not distracted to react in time to prevent a crash. As the clips I posted above demonstrate, I wouldn't bet my or anyone else's life that that is the case.
A fatal collision can kill more than one person. Also, more than one car was impacted by the slowdown so you need to look at the overall odds per person not per car and then sum then to find the collective risk of death.
It's not easy to find the actual odds, but stopped cars on the freeway kill people every year with much higher risks in high speed low density high speed traffic as traffic jams tend to be safe it's unexpected stopped cars that's the problem.
Rough guess there is probably a 1:100 chance per year a car will stop in the middle of a free way for no apparent reason. There ~100,000,000 cars on the road. So, ~1:1,000,000 cars stop per year which is probably low but let's say they cause 10 deaths out of the 20,000+ auto deaths per year. Well that's ~1:10,000. Now, sure you
can play with the odds but there much higher than 1:1,000,000.
They sent known commands to a known vehicle, they weren't live-fuzzing an unknown system.
The experiment seems less dangerous than not following decent tire-rotation policy, etc.
It's not that there's finite extra risk, it's what it is in relation to the baseline risk. Without that these comments are just useless scaremongering.
The problem is there were other drivers around who may not have been expecting the situation.
Further, since they weren't in the vehicle, if something happened ahead of it and the Wired journalist NEEDED to make a sudden maneuver to avoid an accident he might not have been able to. Asking them over the radio to turn X back on could have taken too long causing a serious accident when without their intervention one could have been easily avoided.
It's not scaremongering. There is a reason you don't interfere with a driver on a public road at high speed. It was extremely irresponsible. There were plenty of ways they could have done the test in controlled circumstances (ask the cops for help, race track, auto test facility, large empty parking lot, etc.).
They took unnecessary risks with possibly fatal consequences. It was irresponsible.
But the unnecessary risk is so close to 0 that it's obviously just manufactured outrage. If you read about this and came here to comment and that's all you can talk about you might as well be trolling.
It's harmful. You're going to make some politician think that's where they should spend their time instead of figuring out why the car company sat on this for so long. Our whole society will lose.
So look, it is not obvious to me that this is all "manufactured outrage", and I (a) know one of these researchers, (b) have spent my career mostly in vuln research, and (c) have wasted some brain cycles thinking about this issue.
I think I mostly agree with Robert Graham's take on this:
Robert Graham thinks mostly the same thing you think, but because he doesn't evoke "anti-vaxx" and "trolling" and say things like "obviously manufactured", he's (1) persuasive and (2) not setting fire to a comment thread by picking fights with people.
You can write whatever you'd like to write. But if you keep writing like this, most people here won't care what you have to say, and in short order they won't be able to see it either, because you're going to get flagged off HN.
It would be helpful to have more people arguing the other side of the conventional wisdom on Miller and Valesek's demo --- more people, that is, arguing the thing you're trying to argue, that the risk was minimal and the upside significant. Please make that argument carefully, and don't caricature it.
'fineman, you have my sympathies. I wonder if some people commenting on this issue have ever driven a vehicle. If they have, they must be the same yokels I see who never change lanes or even deviate from their lane ever, even on multilane roads: not to pass a cyclist, not because the car in front of them is stopping to turn right into a narrow drive, not to give the flag dude a little more room, never!!!
Interestingly enough, when my car is moving I cannot reconfigure the car. Those functions are disabled. However, I fully expect if that if my car was hacked, they could easily by-pass that restriction.
Perhaps a small proxy application that is fully vetted and tested code. This doesn't seem too dissimilar from the "I need a small suid root app to do $root_thing for an unprivileged user". As you said, unrestricted access is the problem. This just is typical "principle of least privilege" kind of stuff.
Totally doable, but it is unbelievable to me the lack of forethought in things like this.
CAN has been around for a long time. I don't think we can blame Bosch that they didn't see from 1985 the pitfalls of someone possibly adding global internet connectivity, nor can we assume they would have advised interconnecting CAN systems with the internet.
I was referring to an application/hardware that sat directly on the CAN bus, not a part of the infotainment system whatsoever. Something totally separate that had only 1 small function, to authorize access to CAN communications for "unprivileged" things such as the infotainment system.
Airframe manufacturers have solved this problem. The car makers need to simply hire some aircraft electronics systems engineers for consultation.
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).
I guess my question would be, why on earth do we need to change vehicle settings through the infotainment system? If you have systems that need to talk to the ECM, you either need to just hook up a tool through the OBD2 port, or have a dedicated interface. I also find the built in cellular link, at best, mildly insane, but under no circumstances should there be any real interconnect between a device that can send and receive with the internet, and the increasingly controlling and complex ECM, as the risks are enormous.
Changing your door lock setting doesn't require the infotainment system, the GUI for it currently does.
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.
Managing all my car settings requires a touchscreen -- should I really have two touch screens for this? No. One screen, one computer, but two processes that are isolated from each other.
In my Rover the K-bus devices do all the stuff that doesn't affect the integrity of the engine management system. It is definitely not connected to the CAN-bus. Why should the locks be connected to the CAN-bus? That's a stupid decision. Locks are the responsibility of the body controller. The K in K-bus means body, in German.
Since you seem to know what you're talking about - can you explain: if the system can be accessed and controlled remotely, why it can't be patched remotely?
Easy to say, hard to do. Really cars now need TWO CAN bus networks, the RED network and the BLUE network. All critical car functions on the RED isolated network, vanity functions on the BLUE network.
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.
They've largely had something like this already in most cars, a low speed bus that's got the non-critical things (seat position controls, window controls, etc.) and a high speed one that has all the things like engine data, speedometer updates, etc.
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".
There are very few "non-critical" systems in a 2+ ton vehicle moving at highway-to-expressway speeds. For an example of what a "minor" system like seat position can do, consider the following:
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.
If an individual does something stupid and gets himself killed, that's one thing. If I can send a broadcast message to cut the brakes, and that can potentially affect many vehicles at once, that's something else entirely and the greater risk to public safety.
I've done some CAN stuff (not on cars though), and that is the way that everyone I talked to advised to build your system, if suitable. However, we still pushed firmware from the master, so if the master were ever compromised, then all of the nodes would be potentially compromised as well. There is only sending and receiving data. All nodes receive any data from anything else on the bus. A node typically ignores data not addressed to itself but not always, that is up to the programmer. Any node can potentially impersonate the master, or another node. There is no way to prevent this, other than through the firmware.
One thing I've not seen addressed in this context: If someone wants to create mayhem on a highway, why would they not go low-tech / low effort? There's a number of mechanical and electrical attacks that I can think of just off the top of my head.
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.)
I'm sure there are some who might want to "create mayhem on a highway" and who would not choose this route. But when your potential attackers are [everyone with an internet connection] this kind of exploit has huge potential. Imagine if the vulnerability were bundled with a popular mobile website or if someone else cracked how to mass-distribute it. Countries that are at war could use it against their enemy. Al-Abu-ISIS-HAMAS-Nidal-Haram-Boko could use it against anyone/everyone.
>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.
There's also inhibitions to talk about. It's one thing to go lay a spike strip down in the middle of the road and it's another to do something over the internet.
A lot of cars have audio controls on the steering wheel. It used to be on separate wires but now that's on CAN, save money. So that's one reason infotainment is on CAN.
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.
It's perfectly reasonable to use the same bus to carry driving and infotainment commands from the wheel - those are simply physical switches. Also, the steering wheel isn't connected to the cellular network.
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.
I'm not disagreeing with you, it's just the realities. For example CAN does not have a notion of source, it's really in the abstract a whole lot like a bus, just with cables.
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.
> For example CAN does not have a notion of source, it's really in the abstract a whole lot like a bus, just with cables.
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.
I thought about this too, but they're replacing the firmware with their own custom firmware OTA. How do you know that your hypothetical "very simple listener" won't be bypassed or re-appropriated for other means?
This sounds like the equivalent of sending UDP over the Internet. If you're receiving UDP from a server, you're not going to get access to the server just because it spouts UDP. If that's the _only_ thing the server does, you're just not going to gain access to it.
It's unfortunate but the reality is that manufacturers are too cheap/lazy to segregate devices on to separate L2 segments, deploy fw or keyed A3E until forced to by exposure of hack demos. In cars (and IoT), standards make everything cheaper but easier to hack without sensible security measures.
It's not just cellular. They also found it was the digital radio, and presumably anything else on that bus. Bluetooth? Key fobs? In-car wifi hotspot? Who knows what other entry vectors there are.
I think that disabling the entertainment center's access to the internet would be the responsible thing to do. Given Toyota's recent $1.2B settlement over the unintended acceleration defect, leaving this door open to hackers could be very costly for Chrysler.
Hell, I'm driving a 2015 Jeep Cherokee as a rental right now and I don't even want it connected to the Internet. But you've gotta have car apps, right? How else would car manufacturers be priming you to accept in-car advertising than an Internet-connected screen that you can't turn off completely?
Perfect network security is a rather big assumption, though, isn't it?
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?
Sure. My point is more that a fix that eliminates the ability for people to just use the internet to manipulate the vehicles removes a great deal of the urgency for corrections on the vehicle side.
What does it mean to you to "eliminate the ability for ..."? To patch the known bug? Or do an audit and fix all the bugs they find? Or unplug the system?
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.
Yeah, that is valid. The vehicle shouldn't be visible on the net.
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.
It does make it less of an emergency but it also means that anyone with malicious intent has a huge incentive to look for a way around the network block because there's a known win if they find one.
Would it be really hard to fix this OTA for all vehicles, reusing (and patching) their own bug? This is a technical question, law might forbid doing this.
> That automobiles are recalled for reasons other than hardware replacement is a recent phenomenon.
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.
No, it's a stopgap. They have to be seen to do something to counter all the bad press. You can be sure they'll be looking at a more definitive and more robust solution in the longer term but in the shorter term they need to be able to say 'this particular hole was plugged'. That's just damage control on their part, nothing more or less.
The problem is that a fix for this particular problem doesn't actually make anyone secure, it only blocks the one specific attack the hacker told them about. (Hopefully the hackers kept another bug in reserve so they can trigger another recall/patch cycle as soon as this is over.)
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.
> The problem is that a fix for this particular problem doesn't actually make anyone secure, it only blocks the one specific attack the hacker told them about.
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 ...
There is simply no alternative at this point. The press coverage was so big (which I prefer) that they can't hope that 100% of users will do the fw upgrade themselves.
That thing here is a big fucking warning to all other car manufactures for the future.
> The recall doesn’t actually require Chrysler owners to bring their cars, trucks and SUVs to a dealer. Instead, they’ll be sent a USB drive with a software update they can install through the port on their vehicle’s dashboard.
> 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.
That's how I get updates on my car. A signed executable from Fiat. It hardly ever works right, and it takes longer than the time you need to fill up with gas. And the car has to remain stationary.
> 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...
The post isn't complaining they'll only block it at the network level, it's complaining that they're trying that at all. The issue is vulnerable cars - not the lack of a firewall between the net and those vulnerable cars.
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.
Chrysler doesn't have much of a choice. They have to do a "voluntary" recall for a safety issue, or the NTSB orders an involuntary recall. Since this has terrorism implications, they need to get this done.
Terrorism implications? Sure, but so does pretty much everything. If terrorists inside the US wanted to mess things up they just need to blow up a small targets in BFE, Iowa and the like. Worse, kidnap a few people and behead them. The US would be utterly paralyzed with fear.
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.
That's a good use for formal software proving. While proving the safety of the entire codebase might be currently out of bridge, it would be quite feasible to prove the safety of a message bridge.
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.