Driving Information Security, From Silicon Valley to Detroit

As published in Wall Street and Technology:

For better or worse, computer software vendors are practically devoid of any liability for vulnerabilities in the software they sell (although there is certainly a heated discussion on this topic). As far as vendors are concerned, software is “licensed” rather than sold, and users who accept those licenses are agreeing to waive certain rights, including the right to collect damages resulting from failures in the software.

To pull one particular example from
the license for Microsoft SQL Server Enterprise 2012, a widely used piece of database software that underpins a significant number of enterprise applications that handle millions of dollars worth of transactions each:

YOU CAN RECOVER FROM MICROSOFT AND ITS SUPPLIERS ONLY DIRECT DAMAGES UP TO THE AMOUNT YOU PAID FOR THE SOFTWARE... YOU CANNOT RECOVER ANY OTHER DAMAGES, INCLUDING CONSEQUENTIAL, LOST PROFITS, SPECIAL, INDIRECT OR INCIDENTAL DAMAGES. 


When a flaw is discovered, including security flaws that are
actively being exploited to breach systems, a vendor will typically issue a patch (sometimes many months later, and, hopefully without causing more problems than they fix), and that is the end of the issue: no lawsuits, no refunds, and no damages.

This liability-free model used by software vendors stands in stark contrast to almost any other product that is bought and sold. Product liability laws hold manufacturers and sellers responsible for design or manufacturing defects in their products. Rather than releasing a fix and calling it a day, these companies will find themselves on the hook financially for the consequences of their failures.

Software infiltrates everything

Government oversight from organizations like the Consumer Product Safety Commission, the National Highway Traffic Safety Administration, and the Food and Drug Administration track complaints and have the ability to force recalls or issue fines. For a recent example of these consequences we can look to General Motors’ ignition recall troubles that have so far resulted in $2.5 billion worth of recalls, fines, and compensation funds.

Most consumer products also don’t receive the frequent software updates that we are used to applying to our computers; whatever software version comes in a consumer product tends to stay in it for life. In the automotive world this has already led to some comically outdated in-dash navigation, information, and entertainment systems (especially when compared to today's rapidly evolving smartphones and tablets) but will also likely lead to some horribly vulnerable unpatched software.

These two worlds, both operating under very different rules, are colliding. Cutting-edge computers and software are increasingly finding their way into the types of products we buy every day, and nowhere is this more apparent than in the automotive world. The days of carbureted vehicles that could be tuned with a timing light and a screwdriver ended in the 1990s, replaced with fuel injection and electronic ignition systems that are controlled by computers actively adjusting engine parameters as we drive, based on the readings from a network of sensors scattered throughout the vehicle. These networks have grown to include more than just the engine sensors.

In-car networking standards, such as the CAN bus standard, enable a wide array of devices within a vehicle to communicate with each other, allowing huge wiring harnesses containing hundreds of bundled wires, fuses, and switches to be replaced with commands and updates traveling over a single wire. On modern cars the brakes may not be controlled by a hydraulic line connected to the brake pedal; the throttle may not be controlled by a cable connected to the gas pedal; and the steering may not be controlled by a shaft connected to the steering wheel. Instead, the brake pedal, gas pedal, and steering wheel could all just be electronic sensors that send computerized commands over the CAN bus network to electric motors elsewhere in the vehicle that carry out those commands. Toyota’s electronic throttle control system has already made some headlines as part of a series of 
unintended acceleration lawsuits that resulted in 16 deaths, 243 injuries, a motorist released from jail, and a $1.2 billion fine.

This issue goes much deeper than the types of software mistakes that can cause a car to malfunction on its own. As we’ve seen with much of the software connected to the Internet, including some other systems that can have real-world (and sometimes 
very messy) consequences, it is the malicious hackers that can cause the most problems. Security researchers have already been looking into these sorts of possibilities and have separately demonstrated the ability to gain access to in-car networks from a remote location and affect a vehicle’s braking, steering, and acceleration (among other things) once they gain access to the in-car network.

Other attacks like location tracking and eavesdropping on a vehicle’s occupants via hands-free communication microphones are also possible, but they pale in comparison to the potentially fatal consequences of interference with the vehicle controls. Presentations at the annual
Black Hat Conference and DEF CON security conferences this month have also covered topics related to automotive network and computer security, while a group in China is offering a prize of $10,000 to anyone who can gain remote access to a Tesla’s on-board operating system.

Although some of the media reports on this topic are being dismissed within the information security community as “stunt hacking” (sensationalist stories based on hacks conducted in unrealistic conditions) and manufacturers are quick to state that their car systems have safety checks built in, it is clear that the building blocks for a real-world attack are being built and assembled. The 
firmware manipulation techniques demonstrated at DEF CON earlier this month could be used to override or eliminate the safety checks built in by the manufacturers, and it is only a matter of time before the techniques that are being used to remotely access cars are combined with the techniques to manipulate the controls.

Many ways to attack

For an attacker, getting access to a car’s network is not as hard as it may initially seem. The most obvious attack point would be the On-Board Diagnostics connector that is usually located in a discrete spot under a vehicle’s steering wheel where a small and cheap micro controller could be connected. More interesting attacks could be launched via malware contained on CDs, DVDs, or USB devices loaded into the vehicle’s infotainment system. Moving into the wireless realm, many cars come equipped with Bluetooth or WiFi connectivity for smartphones and other devices within the vehicle.

All of these attack vectors would require the attacker to be in or near the target vehicle, but services like GM’s OnStar, BMW’s Assist, and others utilize mobile cellular connections to connect vehicles to the outside world. New smartphone apps that allow vehicle owners to interface with their cars remotely can open up these interfaces essentially to anyone on the Internet. It’s not too far-fetched to imagine that a few years from now bored Chinese hackers could spend their downtime crashing cars instead of 
trying to cause trouble at water treatment plants.

Motor vehicles have been built with mechanical and hydraulic linkages for over a century, and the basic safety principles for those types of systems are well understood. Designing reliable software for complex vehicles is a fairly new discipline that is only understood by 
a few companies (and even they make mistakes). Malfunctions or outside interference with operating vehicles can easily have fatal consequences, and the increasing use of networked control systems connected to the outside world increases the likelihood of accidental or malicious incidents.

The developers of the electronic systems in our vehicles would do well to heed the the saying “with great power comes great responsibility.” As we’ve seen with both Toyota and GM’s recent troubles, safety issues can bring heavy financial consequences for manufacturers. Congress is starting to 
pay attention to the issue of car hacking as well, and it will likely only take one high-profile incident to provoke regulatory action.

Tesla Motors has already shaken up the industry by bringing its Silicon Valley approach to the automobile business and continues with this approach by 
actively soliciting information from the public on security vulnerabilities in its vehicles and publicly posting a “Hall of Fame” for security researchers who have assisted them. Perhaps this is part of the future, manufacturers working closer with their customers to find and address issues.

As Google experiments with some of the first realistic self-driving cars, it isn’t too far fetched to imagine them following the same path as Tesla when it comes to working with security researchers, especially in light of Google’s existing 
bug bounty programs. In any case, one habit of Silicon Valley that we can be almost assured won’t carry over to the automotive world is the practice of disclaiming liability for damages from the improper operation of software; the Toyota case has shown us that those days are already over. Who knows? Before long, it may be Silicon Valley looking to Detroit for advice on how to handle product liability concerns.

As a footnote, many of the issues raised here are applicable to other industries outside the automotive sector as well (software vulnerabilities in medical devices and industrial control systems have been getting quite a bit of attention as of late). But it’s hard to imagine any other industry that is as integral to the national (and global) economy, whose products are used more frequently by such a large proportion of the population, and the correct operation of which carries life-and-death consequences.