“Hello, I’m a VxWorks device. Would you like to own me?”
Dave makes some "interesting" claims in his blog. Here's a quote:
This may sound eerily similar to my car hacking blog which discusses how a diagnostics port was used to subvert a car’s brakes and engine. What I didn’t mention then is that this hacked system also runs an RTOS: QNX.
Hmmm. Sounds damning, doesn't it? He follows this with an immediate pitch for a GreenHills Security Kernel product. I work for QNX, so I just had to look further.
I read the actual academic report that he bases his "information" on. Dave apparently doesn't understand cars or doesn't understand what problems his own company's product is supposed to solve. The reasoning used to implicate QNX by interpreting the academic report is faulty at best. The premise of the study is that with an OBDII tool you can send arbitrary messages on the vehicle bus. Since every car has an OBDII port (by government mandate for emissions monitoring and control), you can "hack" into every car. This "hacking" allows you to do all types of things to the car, from shut off the engine, control the brakes, reflash the telematics unit, etc.
In a word (or maybe two), "no duh". When you bring your car into the dealership, how do you think the techs communicate with it? They don't whisper it back to health! The paper describes doing things to the car while moving: they've set up a laptop with WiFi that they've plugged into the vehicle bus while driving along side in a chaser car. Not exactly something that is practical without physical access to your car. One of the things done in the hacking test is to replace the telematics unit firmware (the module running QNX) with a custom firmware image that lets them transfer messages between the low-speed and high-speed CAN buses as a bridge.
Oh my goodness! How could QNX allow a hacker to replace the RTOS firmware image?! In fact it's not a surprise, because that requirement is written into the specification. That's right. For a dealership to update the modules within the car, those modules need to be able to be reflashed. Every module has this requirement. I don't care if your car module is running the QNX Neutrino RTOS, or the QNX Neutrino RTOS Safe Kernel, or the GreenHills Superfragilisticexpialidocious kernel or Kumquat OS 9.9. If the module is actually operating properly, it will allow itself to be reflashed. Period. The purported problem cannot be solved by use of a security kernel whether from GreenHills or anybody else.
The true problem being pointed out by the academics is that the car vehicle network, for better or worse, was designed as if it were a closed system. The only thing that prevents malicious mischief is the difficulty of gaining physical access to the vehicle bus connectors. I would agree that vehicle buses probably need to start considering authentication / identity verification / challenge / response protocols in their design. Because the dealers will always have the requirement to fix/diagnose/update cars, they will have access to tools to let you do this. No matter what you could design to solve the "closed network" problem, it can be abused by unscrupulous people.