One In Five Vehicle Software Vulnerabilities Are 'Hair On Fire' Critical (securityledger.com)

Long-time Slashdot reader chicksdaddy quotes a report from Security Ledger: One of every five software vulnerabilities discovered in vehicles in the last three years are rated "critical" and are unlikely to be resolved through after the fact security fixes, according to an analysis by the firm IOActive. "These are the high priority 'hair on fire' vulnerabilities that are easily discovered and exploited and can cause major impacts to the system or component," the firm said in its report...

The bulk of vulnerabilities that were identified stemmed from a failure by automakers and suppliers to follow security best practices including designing in security or applying secure development lifecycle (SDL) practices to software creation... The result is that vehicle cybersecurity vulnerabilities are not solvable using "bolt-on" solutions, IOActive concluded...
The article argues we're years away from standards or regulations, while describing auto-makers as "wedded to the notion that keeping the details of their systems secret will ensure security."

Comments

Air gap or hardware interlock critical systems FFS

[StandardCell]

The recently publicized vulnerabilities in connected vehicles are examples of vehicle designers not understanding security threat models correctly (which also applies to IoT in general). In the rush for convenience and connectivity it is mind boggling that they wouldn't make more effort if for no other reason than to avoid the negative publicity.

The easiest thing to do in these critical vehicle systems systems is to outright air gap them. There is no reason that there should be any network connection to the autopilot or auto-parking or braking system of a vehicle unless the threat model and the subsequent design of security was sufficiently thorough. Until that happens, it should literally be a discrete action by the driver through a physical interface inside the vehicle and at most have a one-way reporting interface that can be picked up by a network interface.

The other thing that can be done is to hardware-interlock the network connection. For example, the steering motor controllers for automatic parking should have a logic AND control to the speed of the vehicle so that anything above a certain speed disables the motor control at a hardware level. At that point, one would have to physically tamper with the vehicle to overcome this safeguard, but if you could do that there's a lot more mayhem you could create anyway.

Re:Air gap or hardware interlock critical systems

[twdorris]

I understand what you're getting at and mostly agree. My only comment is that once you design these big in-vehicle fully-connected systems to do stuff like report on steering angle and live fuel pressure or whatever else, it's awfully tempting to turn around and implement the PUT or POST to go along with those GET APIs so that all your dealer diagnostics and datalogging tools just hook into the same point everything else does. It reduces the number of different systems and interfaces you have to design, implement and debug.

I have no data on this, but I suspect cost cutting measures have to be insane at auto makers. I recall buying a nice turbo AWD Eclipse in the mid-90s for nearly $30k. Twenty years later and I can still buy a nice turbo AWD car for just a little more than that and this new car will have VASTLY superior features all around. The cost difference barely accounts for inflation. How they also crammed so much new tech and new hardware into it for what's effectively the same price today as it was 20 years ago boggles my mind.

So I suspect this all comes down to trying to push more stuff through that new system to save a few bucks somewhere and then skipping that whole "security" check in the process.

They're CARS, FFS!!!

[jenningsthecat]

I get that digital technology has brought a lot to the party when it comes to efficiency, emissions, and other important performance metrics. But cars are one-tonne-plus hunks of metal which contain human beings and regularly travel at speeds in excess of 30 metres per second. Do we really want them connected to the same Internet used by Nigerian scammers, Ashley Madison hackers, and Donald Trump?

The IOT - I guess it's not just for toasters any more...

The underlying problem

[Opportunist]

Back in the early 80s when Bosch invented the CAN bus, security was a non-issue. For more than one reason. First, no critical system of the car was part of the bus system. It was mostly used to easily bundle electronics so you don't have to run 200 cables across the car just to transmit different signals. Second, microelectronic wasn't so advanced that you could implement some huge protocols with security in mind, you were lucky if you found chips that could at least find out what signals were for them. And third, there was no "open ends" so to speak, there was no bluetooth, no wifi and most of all none of all this ended at the user side of the car, the user had zero chance to mess with the whole deal.

But you know how it is, things grow and specs don't change. Because if you changed them, the existing technology wouldn't be compatible anymore, you'd have to develop new shit, your workers would have to be retrained and in the end, the whole crap simply costs more.

And today we're now at this mess where we have a totally insecure bus that pretty much takes whatever signal you put into it without bothering to question the source that connects mission critical systems (from door opening to brakes) along with user space gadgets, and of course wifi, bluetooth and various other ways to connect wirelessly, from inside or outside the car.

It does not take an expert in information security to see why this could possibly hint at being a wee bit of a potential problem, does it?