Monday, August 15, 2016

Automotive software: unsafe at any speed

The problem isn't that there's software bugs.  The problem is an engineering culture that ensures that security problems are designed in and not fixed:
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, which it released last week. The report was based on an analysis of more than 150 vehicle security flaws identified over three years by IOActive or publicly disclosed by way of third-party firms.
Where do all these "hair on fire" vulnerabilities come from?
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. “These are all great things that the software industry learned as it has progressed in the last 20 years. But (automakers) are not doing them.”
So the auto makers have basically ignored what the rest of the world has learned over the last two decades.  Got it.
The result is that vehicle cybersecurity vulnerabilities are not solvable using “bolt-on” solutions, IOActive concluded. That is because they are caused by flawed engineering assumptions or insecure development best practices. “The most effective cybersecurity work occurs during the planning, design and early implementation phases of products, with the difficulty and cost of remediation increasing in correlation with product age and complexity,” IOActive’s report notes.
Err, so the auto makers have basically ignored what the rest of the world has learned over the last two decades ...
Still, auto firms remain wary of information security firms and wedded to the notion that keeping the details of their systems secret will ensure security (aka “security through obscurity”).
“Their general attitude is that they don’t want to  engage researchers or share their ‘secret sauce,'” Thuen said. “The attitude is anti-security in general. It’s the Ostrich approach – we’re going to stick our head in the sand and say that we can’t hear you, or that everthing you’re saying isn’t important.”
What could possibly go wrong?  Oh yeah, problems not fixable once you release ...
Resistance to the attentions of security researchers is rooted in an engineering culture that looks on software vulnerabilities as shameful – far different from software-based engineering that generally accepts vulnerabilities as an inevitable byproduct of writing code. “It’s not shameful to have vulnerabilities. What is shameful is to have them and not move forward to fixing them,” he said.
So failure is inevitable.  I cannot say more strongly that I will not buy any "connected" car, ever.  And I will not ride in a self-driving car, ever.  There are too may ways that this breaks and the culture that builds them simply doesn't care.

7 comments:

Rev. Paul said...

I'm going to march right down to the auto dealer & buy myself a nice, shiny new '67 Impala. Oh, wait...

It's getting harder to find vehicles which aren't wi-fi/Bluetooth enabled. But no one says you have to turn those features on. I think.

R.K. Brumbelow said...

BP,
How is a self driving vehicle different from a taxi or piloted vehicle? If the concern is that you might become a target then unless you are willing to do a full check on every operator you encounter, it is pointless, you can still be targeted trivially. If the concern is a connected vehicle can be hacked as a terrorist operation, where random vehicles are attacked sparingly rather than wholesale (thus spreading terror like the tylenol cyanide scares) then it seems the solution is to disable non-local data updates (fry the comports and antenae).

At this point, GPS is trivially spoofed and so it is untrustworthy, anyone with physical access to a device can modify it so as to make it weaponized, so what vehicles are safe? Do you weigh your vehicle upon entry and exit to camp Borepatch? Do you do an intergity check and pink noise scan also?

I personally am waiting for a time when the terrorists get smart enough to start attaching munitions to unrelated vehicles and setting random timers on the munitions. Think how easy it would be to simply attach thermite to a drive train with a sensor for velocity, when a vehicle reaches 45mph it selects a random number and begins a countdown, upon completing it ignites a thermal charge on the drivetrain cutting off a wheel, 5 minutes later a second charge lights up the fuel tank. All done for less than $100 per vehicle, how many would it take before people were simply to terrified to drive anywhere. And if they targetted people randomly, it would be real terror as you would never know whose car was a mobile bomb. With more money you could attach a kilo of C4. Again, the idea is to strike terror into people, not nescessarily kill a bunch of people at a time. Fortunately, most terrorists are stupid.

My point is, it is not the right mindset to trust, nor even trust but verify, instead one must presume that anything is capable of being weaponized and treat it accordingly.

matism said...

You have to admit that these "security vulnerabilities" make life a whole lot easier for any "Law Enforcement" who may believe that certain individuals are "problematic". Not that any "Law Enforcement" would EVER consider doing anything untoward to such an individual without due process, of course...

Doug Cranmer said...

Software engineering. An oxymoron if there ever was one.

Old NFO said...

Yep, makes that 60s hot rod look better every day... :-)

matism said...

Well, Old NFO, from an EMP standpoint that is probably true. Although what testing they have done hasn't shown any significant increase in vehicle problems for electronically controlled vehicles as long as the vehicle was turned off when the EMP EMP'd. But for anything other than that issue, an electronically controlled vehicle without any way to tie an RF receive function to the vehicle controllers should not be a concern. Note that OnStar does receive, and I believe it can activate SOME vehicle systems, so anything which might have that onboard, whether or not it's activated, should be a flashing red light. Same for any similar systems by other vehicle designers.

Comrade Misfit said...

I'm keeping my non-connected Honda running until the wheels rust off. Then I'll go to SoCal and find another one.