There was no security track at the 2012 Automotive
but numerous sessions and the "hallway track"
featured anecdotes about the ease of compromising car
computers. This is no surprise: as Linux makes inroads into
automotive computing, the security question takes on an urgency not
found on desktops and
servers. Too often, though, Linux and open source
software in general are perceived as insufficiently battle-hardened
for the safety-critical needs of highway speed computing —
reading the comments on an automotive Linux news story it is easy to find
a skeptic scoffing that he or she would not trust Linux to manage the
engine, brakes, or airbags. While hackers in other embedded
Linux realms may understandably feel miffed at such a slight, the
bigger problem is said skeptic's presumption that a modern Linux-free
car is a secure environment — which is demonstrably untrue.
First, there is a mistaken assumption that computing is not
yet a pervasive part of modern automobiles. Likewise mistaken
is the assumption that safety-critical systems (such as the
aforementioned brakes, airbags, and engine) are properly isolated from
low-security components (like the entertainment head unit) and are not
vulnerable to attack. It is also incorrectly assumed that the low-security
systems themselves do not harbor risks to drivers and passengers. In
reality, modern cars have shipped with multiple embedded computers for years
(many of which are mandatory by government order), presenting a large
attack surface with numerous risks to personal safety, theft,
eavesdropping, and other exploits. But rather than exacerbating this
situation, Linux and open source adoption stand to improve it.
There is an abundance of research dealing with hypothetical exploits
to automotive computers, but the seminal work on practical exploits
is a pair of papers from the Center for Automotive Embedded
Systems Security (CAESS), a team from the University of California San
Diego and the University of Washington. CAESS published a 2010 report [PDF]
detailing attacks that they managed to implement against a pair of late-model
sedans via the vehicles' Controller Area Network (CAN) bus, and a
2011 report [PDF] detailing how they managed to access the CAN network from
outside the car, including through service station diagnostic scanners,
Bluetooth, FM radio, and cellular modem.
The 2010 paper begins by addressing the connectivity of modern cars.
CAESS did not disclose the brand of vehicle they experimented on
(although car mavens could probably identify it from the photographs),
but they purchased two vehicles and experimented with them on the lab
bench, on a garage lift, and finally on a closed test track. The cars
were not high-end, but they provided a wide range of targets.
Embedded electronic control units (ECUs) are found all over the
automobile, monitoring and reporting on everything from the engine to
the door locks, not to mention lighting, environmental controls, the
dash instrument panel, tire pressure sensors, steering, braking, and
Not every ECU is designed to control a portion of the
vehicle, but due to the nature of the CAN bus, any ECU can be used to
mount an attack. CAN is roughly equivalent to a link-layer protocol,
but it is broadcast-only, does not employ source addressing or
authentication, and is easily susceptible to denial-of-service attacks
(either through simple flooding or by broadcasting messages with
high-priority message IDs, which force all other nodes to back off and
wait). With a device plugged into the CAN bus (such as through the
OBD-II port mandatory on all 1995-or-newer vehicles in the US),
attackers can spoof messages from any ECU. There are often
higher-level protocols employed, but CAESS was able to
reverse-engineer the protocols in its test vehicles and found security
holes that allow attackers to brute-force the challenge-response
system in a matter of days.
CAESS's test vehicles did separate the CAN bus into high-priority and
low-priority segments, providing a measure of isolation. However,
this also proved to be inadequate, as there were a number of ECUs
that were connected to both segments and which could therefore be used to bridge
messages between them. That set-up is not an error, however; despite
common thinking on the subject, quite a few features demanded by car
buyers rely on coordinating between the high- and low-priority
For example, electronic stability control involves measuring
wheel speed, steering angle, throttle, and brakes. Cruise control
involves throttle, brakes, speedometer readings, and possibly
ultra-sonic range sensors (for collision avoidance). Even the lowly
door lock must be connected to multiple systems: wireless key fobs,
speed sensors (to lock the doors when in motion), and the cellular
network (so that remote roadside assistance can unlock the car).
The paper details a number of attacks the team deployed against the
test vehicles. The team wrote a tool called CarShark to
analyze and inject CAN bus packets, which provided a method to mount
many attacks. However, the vehicle's diagnostic service (called
DeviceControl) also proved to be a useful platform for attack.
DeviceControl is intended for use by dealers and service stations, but
it was easy to reverse engineer, and subsequently allowed a number of
additional attacks (such as sending an ECU the "disable all CAN bus
communication" command, which effectively shuts off part of the car).
The actual attacks tested include some startlingly dangerous tricks,
such as disabling the brakes. But the team also managed to create
combined attacks that put drivers at risk even with "low risk"
components — displaying false speedometer or fuel gauge
readings, disabling dash and interior lights, and so forth.
Ultimately the team was able to gain control of every ECU in the car,
load and execute custom software, and erase traces of the attack.
Some of these attacks exploited components that did not adhere to the
protocol specification. For example, several ECUs allowed their firmware to be
re-flashed while the car was in motion, which is expressly forbidden
for obvious safety reasons. Other attacks were enabled by
run-of-the-mill implementation errors, such as components that re-used
the same challenge-response seed value every time they were
power-cycled. But ultimately, the critical factor was the fact that
any device on the vehicle's internal bus can be used to mount an
attack; there is no "lock box" protecting the vital systems, and the
protocol at the core of the network lacks fundamental security features
taken for granted on other computing platforms.
Of course, all of the attacks described in the 2010 paper relied on an
attacker with direct access to the vehicle. That did not necessarily
mean ongoing access; they explained that a dongle attached to
the OBD-II port could work at cracking the challenge-response system
while left unattended. But, even though there are a number of
individuals with access to a driver's car over the course of a year
(from mechanics to valets), direct access is still a hurdle.
The 2011 paper looked at vectors to attack the car remotely, to assess
the potential for an attacker to gain access to the car's internal CAN
bus, at which point any of the attacks crafted in the 2010 paper could
easily be executed. It considered three scenarios: indirect physical
access, short-range wireless networking, and long-range wireless
networking. As one might fear, all three presented opportunities.
The indirect physical access involved compromising the CD player and
the dealership or service station's scanning equipment, which
is physically connected to the car while in the shop for diagnosis.
CAESS found that the model of diagnostic scanner used (which adhered
to a 2004 US government mandated standard called PassThru) was an embedded
Linux device internally, even though it was only used to interface
with a Windows application running on the shop's computer. However,
the scanner was equipped with WiFi, and broadcasts its address and
open TCP port in the clear. The diagnostic application API is
undocumented, but the team sniffed the traffic and found several
exploitable buffer overflows — not to mention extraneous services
like telnet also running on the scanner itself. Taking
control of the scanner and programming it to upload malicious code to
vehicles was little additional trouble.
The CD player attack was different; it started with the CD player's
firmware update facility (which loads new firmware onto the player if
a properly-named file is found on an inserted disc). But the player
can also decode compressed audio files, including undocumented
variants of Windows Media Audio (.WMA) files. CAESS found a buffer
overflow in the .WMA player code, which in turn allowed the team to
load arbitrary code onto the player. As an added bonus, the .WMA file
containing the exploit plays fine on a PC, making it harder to detect.
The short-range wireless attack involved attacking the head unit's
Bluetooth functionality. The team found that a compromised Android
device could be loaded with a trojan horse application designed to
upload malicious code to the car whenever it paired. A second option
was even more troubling; the team discovered that the car's Bluetooth stack
would respond to pairing requests initiated without user
intervention. Successfully pairing a covert Bluetooth device still
required correctly guessing the four-digit authorization PIN, but
since the pairing bypassed the user interface, the attacker could make
repeated attempts without those attempts being logged — and,
once successful, the paired device does not show up in the head
unit's interface, so it cannot be removed.
Finally, the long-range wireless attack gained access to the car's CAN
network through the cellular-connected telematics unit (which handles
retrieving data for the navigation system, but is also used to connect
to the car maker's remote service center for roadside assistance and
other tasks). CAESS discovered that although the telematics unit
could use a cellular data connection, it also used a software modem
application to encode digital data in an audio call — for
greater reliability in less-connected regions.
reverse-engineered the signaling and data protocols used by this
software modem, and were subsequently able to call the car from
another cellular device, eventually uploading malicious code through
yet another buffer overflow. Even more disturbingly, the team encoded
this attack into an audio file, then played it back from an MP3 player
into a phone handset, again seizing control over the car.
The team also demonstrated several post-compromise attack-triggering
methods, such as delaying activation of the malicious code payload
until a particular geographic location was reached, or a particular
sensor value (e.g., speed or tire pressure) was read. It also managed
to trigger execution of the payload by using a short-range FM
transmitter to broadcast a specially-encoded Radio Data System (RDS)
message, which vehicles' FM receivers and navigation units decode.
The same attack could be performed over longer distances with a more
Among the practical exploits outlined in the paper are recording
audio through the car's microphone and uploading it to a remote
server, and connecting the car's telematics unit to a hidden IRC
channel, from which attackers can send arbitrary commands
at their leisure. The team speculates on the feasibility of turning
this last attack into a commercial enterprise, building "botnet" style
networks of compromised cars, and on car thieves logging car makes and
models in bulk and selling access to stolen cars in advance, based on
the illicit buyers' preferences.
What about Linux?
If, as CAESS seems to have found, the state-of-the-art is so poor in
automotive computing security, the question becomes how Linux (and
related open source projects) could improve the situation. Certainly
some of the problems the team encountered are out of scope for
automotive Linux projects. For example, several of the simpler ECUs
are unsophisticated microcontrollers; the fact that some of them ship
from the factory with blatant flaws (such as a broken
challenge-response algorithm) is the fault of the manufacturer. But
Linux is expected to run on the higher-end ECUs, such as the IVI head
unit and telematics system, and these components were the nexus for
the more sophisticated attacks.
Several of the sophisticated attacks employed by CAESS relied on
security holes found in application code. The team acknowledged that
standard security practices (like stack cookies and address space
randomization) that are established practice in other computing
environments simply have not been adopted in automotive system
development for lack of perceived need. Clearly, recognizing that
risk and writing more secure application code would improve things,
regardless of the operating system in question. But the fact that
Linux is so widely deployed elsewhere means that more
security-conscious code is available for the taking than there is for
any other embedded platform.
Consider the Bluetooth attack, for example. Sure, with a little
effort, one might could envision a scenario when unattended Bluetooth
pairing is desirable — but in practice, Linux's dominance in the
mobile device space means there is a greater likelihood that developers would
quickly find and patch the problem than would any tier one supplier working
One step further is the advantage gained by having Linux serve as a
common platform used by multiple manufacturers. CAESS observed in its
2011 paper that the "glue code" linking discrete modules together was
the greatest source of exploits (e.g., the PassThru diagnostic
scanning device), saying "virtually all vulnerabilities emerged
at the interface boundaries between code written by distinct
organizations." It also noted that this was an artifact of the
automotive supply chain itself, in which individual components were
contracted out to separate companies working from specifications, then
integrated by the car maker once delivered:
Thus, while each supplier does unit testing (according to the
specification) it is difficult for the manufacturer to evaluate
security vulnerabilities that emerge at the integration
stage. Traditional kinds of automated analysis and code reviews
cannot be applied and assumptions not embodied in the
specifications are difficult to unravel. Therefore, while
this outsourcing process might have been appropriate for
purely mechanical systems, it is no longer appropriate for
digital systems that have the potential for remote compromise.
A common platform employed by multiple suppliers would go a long way
toward minimizing this type of issue, and that approach can only work
if the platform is open source.
Finally, the terrifying scope of the attacks carried out in the 2010
paper (and if one does not find them terrifying, one needs to read
them again) ultimately trace back to the insecure design of CAN bus.
CAN bus needs to be replaced; working with a standard IP stack,
instead, means not having to reinvent the wheel. The networking angle
has several factors not addressed in CAESS's papers, of course —
most notably the still-emerging standards for vehicle ad-hoc
networking (intended to serve as a vehicle-to-vehicle and
On that subject, Maxim Raya and Jean-Pierre Hubaux recommend
using public-key infrastructure and other
well-known practices from the general Internet communications realm.
While there might be some skeptics who would argue with Linux's
first-class position as a general networking platform, it should be
clear to all that proprietary lock-in to a single-vendor solution
would do little to improve the vehicle networking problem.
Those on the outside may find the recent push toward Linux in the
automotive industry frustratingly slow — after all, there is
still no GENIVI code visible to non-members. But to conclude that the
pace of development indicates Linux is not up to the task would be a
mistake. The reality is that the automotive computing problem is enormous
in scope — even considering security alone — and Linux and
open source might be the only way to get it under control.
to post comments)