Hackers are smart. Could they hack a self-driving car through its CD drive? From what I understand, malicious code could be uploaded to the driverless car via CD which could give them access to brakes, windscreen wipers, sensors, etc. (all of which could be used to potentially commit murder or hold the car ransom).
-
15Any system could theoretically be hacked from any means of input. But that does not mean that the system could not be implemented in a reasonably secure way.– AndersOct 11, 2016 at 13:23
-
59Or, y'know, just build the system in a way where the CD player is completely separate from anything critical?– James HydeOct 11, 2016 at 13:31
-
11Most systems that I have seen have direct access via the SD card slot usually to update maps. I would be more concerned with that then a CD. In most systems in today's environment, the CD player will skip anything that isn't either .WAV(Raw) or a coded format that it understands. Doesn't mean it cannot be used as a DOS, I had a CD player in an older Mazda that we had created a disk with a couple hundred thousand filenames and it would get so hung up that it wouldn't even let you eject the disk. I had to take the drive out and use the manual eject pin method.– Kevin B BurnsOct 11, 2016 at 14:36
-
12An attack via CD player requires physical access. I suppose the saying about physical access to computers can be extended to cars (driverless or not)– Hagen von EitzenOct 11, 2016 at 15:20
-
13@CortAmmon But, with a CD player in the car, he could listen to his favourite music while cutting the brake lines. That would be more enjoyable, so he would be more likely to do it. Therefore, CD players are a security risk.– David RicherbyOct 11, 2016 at 17:19
|
Show 9 more comments
6 Answers
Not on a well-designed car
The CD player is part of the media system. It's likely that the media system has a number of security vulnerabilities, and a malicious CD can probably take control of the media system. It would be difficult to fix this without either greatly increasing the cost, or restricting the functionality of this.
The car control systems - the CAN bus - should be strongly separated from the media systems. In previous attacks, like Jeep hacking, attackers have been able to break across from the media system to the CAN bus. However, this represents poor design and implementation. The two systems should be kept separate - or at least, have a highly restricted interface - and it is possible to do that at reasonable cost.
Whether any future driverless cars will be well designed remains to be seen.
-
65"Whether any future driverless cars will be well designed remains to be seen." Oct 11, 2016 at 13:53
-
8You should amend your answer to: "Yes, but it shouldn't on a well designed car". Time and time again we see this kind of hack take place. I'm not familiar with these systems, but given the current trends I doubt that they're using an "air gap" between the systems.– DavidOct 11, 2016 at 14:57
-
17While I think this is a true answer, it's a bit of a tautology. If I may paraphrase, "the CD player is safe as long as the car is designed such that the CD player is safe." Any cars which are connected in a way which permits a hacker to take over are automatically marked as "not well designed," so it's a bit cheating. Oct 11, 2016 at 16:43
-
5In the Chrysler hack, the two systems did have a highly restricted interface. But not highly restricted enough. See this presentation from DEF CON 23. Oct 11, 2016 at 21:09
-
2@MichaelHampton: The appropriate kind of restriction on the interface would be dataflow in one direction only (at physical not only logical level, i.e. no sending read requests or flow control). Although there's a great deal of spying that might be enabled by sending car information to the media center, it won't ever allow taking control of the car. Oct 11, 2016 at 21:30
Yes, it would.
Researchers from UC San Diego actually implemented an attack through this vector:
“We found a flaw in a CD player in our car,” he said. “You could pick a song and code it in a way that if you played on your PC it’ll play fine, but if you play it in your car, it’ll take it over.”
Most probably this is through a memory corruption vulnerability in the meta information tags in the audio file. Through this they were probably able to direct commands to the CAN system that regulates the car.
But you don't even need a CD; in the worst case it can happen remotely through mobile networks
-
1Suppose this would be an inconvenience to the attacker to say the least... Guess we're safe claps Oct 11, 2016 at 12:27
-
Except for the part about hacking remotely through mobile networks ;( Oct 11, 2016 at 12:29
-
2It bugs me that C compiler writers don't recognize as a commonplace requirement the notion that programs which are given invalid input data be allowed to produce arbitrary output data, but the output format and other behaviors must remain defined. If programmers don't care what pixel or audio samples are generated from an invalid file, subject to the above constraints, requiring that programmers rigidly handle all corner cases will not only create security holes whenever programmers fail to do so, but it will hurt performance when they do (vs. letting compilers have more freedom).– supercatOct 11, 2016 at 15:33
-
4@supercat: A C compiler couldn't possibly take on the burden of maintaining "output format and other behaviors" for buggy programs. Even figuring out what the correct output format is would require the compiler to read the programmer's mind. Even far safer languages like Rust or Haskell can't make that kind of guarantee. Oct 11, 2016 at 23:59
-
2@supercat The compiler might well compile a function so that it produces invalid output data given invalid input data, with no other ill side effects. But then the output from that function is used as an index into a table of function pointers, which causes the
send_command_to_enginefunction to be called instead of theplay_musicfunction, for example. Oct 12, 2016 at 4:05
Never mind the CD player, your tires are conspiring against you
"Security and Privacy Vulnerabilities of In-Car Wireless Networks: A Tire Pressure Monitoring System Case Study"
We also found out that current implementations do not appear to follow basic security practices. Messages are not authenticated and the vehicle ECU also does not appear to use input validation. We were able to inject spoofed messages and illuminate the low tire pressure warning lights on a car traveling at highway speeds from another nearby car, and managed to disable the TPMS ECU by leveraging packet spoofing to repeatedly turn on and off warning lights.
Speaking from personal experience here, not a snowballs chance in hell.
I was part of a team that wrote a fully new device stack for an automotive infotainment system back in 2008. Quite a while ago, but even then we understood the critical need to protect our software stack.
Our problem was made worse because the system ran (and runs) on Linux. And we fully complied with the GPL 2 terms, which means that you could put in a self-developed code and the car would accept that.
However, this was specifically not a security risk because the car used a digital signature system. Your own code would run, but the car simply refused to talk to your software. And it didn't listen anyway - the infotainment system at best had read-only access to a small set of enumerated data items such as the car speed.
I know that our system was at the cutting edge of automotive engineering at the time, and the already mentioned Jeep hack happened later. That's not really surprising. There's quite a bit of legacy going on, clean sheet redesigns aren't that common. Jeep is of course a minor brand of a struggling company, so it doesn't come as a big surprise that they are lagging. But that wouldn't be a brand which you'd expect would first produce a driverless car - the chief suspects would more healthy companies (could be Mercedes, could be Toyota, and of course Tesla)
-
5Re: "not a snowballs chance in hell". The OP didn't ask about "Your CD system", I think they meant any system. You then seem to disprove your comment by listing cases that did have issues and dismiss them as though there won't be those kinds of companies in the driverless car industry. Additionally, while a system may be secure, it is only secure against the things the developers were able to think of protecting against. I hope your processor wasn't built in China, otherwise who knows what back doors are waiting to be utilized.– DunkOct 11, 2016 at 22:03
-
2Was your security model to link the car control and infotainment systems, and harden the infotainment system? Sounds like you took security seriously, but I still think that's a risky design. The perimeter attack surface is massive, and presumably includes things like MP3 decoders that need to be high performance.– paj28Oct 11, 2016 at 22:40
-
1I'd agree with @paj28 - "not a snowballs chance in hell" is pretty hard claim. Digital signatures depend on cryptography implementations, and crypto algorithms themselves are found weak and exploitable with time, not to mention that their implementations often have bugs too. Then there are all side channel (like timing) attacks etc. Read only access also perhaps can be exploited for writing via bugs (for example, in access controls themselves - like kernels, hypervisors) or in hardware itself (remember rowhammer?). Oct 12, 2016 at 1:13
-
1@Dunk: Considering that we needed the processor to boot only signed kernels, and it's an automotive product, you can assume it's not some random Chinese bit. Yes, there's a "hidden from the OS" security module in there - that's the whole reason we can enforce the digital signing.– MSaltersOct 12, 2016 at 7:10
-
2@paj28: The model wasn't to "harden" the infotainment system. The model was to consider it compromised by default - who knows what sort of unsigned code it might be running? Down to the the drivers, the whole kernel source was available. This greatly narrows down the attack surface.– MSaltersOct 12, 2016 at 7:13
Security on self driving cars are becoming a trending topic, as cars get more and more software.
The more code and hardware there is the more exposed is the system because the surface of attack is bigger. That said I wouldn't worry too much about the CD drive. Most recent self driving car will be connected to the internet to get various data (weather, traffic, stream music, sync calendar, etc etc). If a car were to be targeted cd wouldn't be a wise choice, and like you said, hacker are smart so they would probably target more modern and open doors to the outside world.
That said, let's pretend there is a flow in your cd drive: the hacker would have to make you download a song, make you burn it to a CD and then hope you'll play it on your self driving car - So if you don't download dodgy files it's basically impossible for them and definitely not worth the effort...
One last thing to add is that the song itself could give somme voice commands to the car if it is compatible (like what they have done for phones). Again you would have to get the song from a dodgy source and this doesn't allow to do something that is not designed to work with the voice interface. So it's pretty unlikely that a song will tell your car to break...
From a developper point of view, I think that self driving cars won't be 100% bulletproof, but they will (and already are) be much much much safer that human operated cars. This is just because a computer has a shorter response time, it is never drunk, sleepy or distracted, it has much more senses. you rely on a 200-220° optical field of view, the computer can rely on a 360 camera system coupled with long range radars, proximity sensor etc...
Let's be honest, when we launch a rocket, it's operated by a computer, not a human, there is a reason for that.
I hope it helped you better understand the risks and be less scared of self driving car.
-
1I'd be pretty afraid of a driverless car controlled by a computer with a slower response time. You either mean faster or shorter. Oct 12, 2016 at 15:48
-
-
When we fly a plane, it's run by a computer, for a reason. When we land a plane, it isn't.– user83389Oct 12, 2016 at 19:47
-
@WilliamKappler both Boeing and Airbus have been piloting (pun intended) computers landing planes; as well as complete computerized flight. Flight or boating might be simpler than ground transportation for a computer.– MikePOct 12, 2016 at 19:58
If it is connected to the systems that run the car, then anything is possible.
If it is not connected, e.g. it is a Discman, then no.
