Car Hacking is 'Distressingly Easy'

Bruce66423 points out a piece from the Economist trying to rally support for pressuring legislators and auto manufacturers to step up security efforts on modern, computer-controlled cars. They say, Taking control remotely of modern cars, for instance, has become distressingly easy for hackers, given the proliferation of wireless-connected processors now used to run everything from keyless entry and engine ignition to brakes, steering, tyre pressure, throttle setting, transmission and anti-collision systems. Today's vehicles have anything from 20 to 100 electronic control units (ECUs) managing their various electro-mechanical systems. ... The problem confronting carmakers everywhere is that, as they add ever more ECUs to their vehicles, to provide more features and convenience for motorists, they unwittingly expand the "attack surface" of their on-board systems. In security terms, this attack surface—the exposure a system presents in terms of its reachable and exploitable vulnerabilities—determines the ease, or otherwise, with which hackers can take control of a system. ... There is no such thing as absolute security. [E]ven firms like Microsoft and Google have been unable to make a web browser that cannot go a few months without needing some critical security patch. Cars are no different.

Comments

Memory Safe Languages As Countermeasure

[Anonymous Coward]

Rust, Swift, Sappeur, Vala - they must also be used in the car industry. Instead of C. Look at the CVE database - 50% of exploits are solely due to the cowboy style of C (lack of memory safety).

Or just roll over and concede that electronics are too dangerous.

Re:Memory Safe Languages As Countermeasure

[BitZtream]

...

Your solution to the problem is to try to kill the problem of bad developers by hiding it with the language.

Could you name one example of where that has actually worked, EVER?

When you write your 3 lines of Swift (lets limit it to languages real people outside of one company actually use), there are possibly a million lines of C could doing the actual work.

You do real work in C. You ride on someone else C code in pretty much every other modern language. Switching them from C to any other language won't solve the problem, the problem is using people who don't think things through. Thats not a language problem is a person problem.

Re:Memory Safe Languages As Countermeasure

[ThosLives]

Five letters generally prevent most of the software *coding* issues found in critical automotive software: MISRA.

Failures that happen in automotive software are almost never coding issues, but rather design issues. For instance, even the "infamous" Toyota brake control issues were due to design, not faulty coding.

Switching languages is actually more likely to introduce more errors than reduce them, since you've now likely added coding errors on top of the design issues.

(And I second the other poster mentioning things like compile-time allocation of all objects. I have never seen a dynamically-allocated anything in any of the embedded programs on which I've worked in the main code stream; closest we came was in a data logger which wrote to a dedicated area of flash, on a separate chip even from the main micro.)

Re:Memory Safe Languages As Countermeasure

[Anonymous Coward]

Could you name one example of where that has actually worked, EVER?

Isn't this basically what Ada was developed to do? And while it is sort of a niche language that no hipster would touch with a ten foot pole, it is often used for some critical systems, no?

Re:FP

[AchilleTalon]

In fact, we don't need cars at all.