Vulnerabilities / Threats
9/8/2011
04:51 PM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Car Systems Reminiscent Of Early PCs

A lack of security scrutiny leads automobile makers to make simple, familiar security mistakes

Today's automobiles are controlled by dozens to hundreds of electronic control units (ECUs) -- embedded controllers connected by different data buses to monitor and control every aspect of a motor vehicle.

While security is taken into consideration by the car manufacturers, the companies have lacked the constant security scrutiny that has benefited -- though some software makers might say "plagued" -- the computer industry. The recent scrutiny has led to the reporting of vulnerabilities and a steady stream of academic papers on the exploitation of automotive control systems.

"No one has really attacked these systems, so there are simple secure programming techniques used in the PC world that are not yet implemented in the embedded world," says Stefan Savage, a professor of computer science and engineering at the University of Southern California at San Diego (UCSD) and author of one recent paper.

It should come as no surprise, then, that more traditional computer security firms see a market. On Wednesday, McAfee and embedded-software maker Wind River released a report surveying research into the security of information control systems in automobiles. In February, the subsidiaries of McAfee and Wind River announced a partnership to bring McAfee's security expertise to bear on embedded systems, including automotive applications.

"We were really struck at how fast embedded devices are being connected in the world," says Tim Fulkerson, senior director of marketing for McAfee Embedded Security. "Cars are really one of the more visible instances of where we encounter embedded systems in real life."

Both companies are subsidiaries of chipmaker Intel, which got its start in the PC world, but which is seeing a greater proportion of income from embedded systems. In its latest quarter, the company saw the revenue of its embedded and communications group jump by 25 percent.

Embedded automotive systems need a good security review, similar to PC software a decade ago and industrial control systems a few years ago. At the USENIX Security Conference in August, for example, researchers from the University of California at San Diego and the University of Washington revealed (pdf) that they had found a number of ways of compromising a car's systems to gain complete control over the vehicle.

In one attack, a compact disc carrying a program masquerading as a song file could exploit a car's entertainment system and, from there, take control of the vehicle. Other attacks involved using Bluetooth or cellular vulnerabilities in the automobile's network interfaces to similarly take control of systems. Because devices typically trust other embedded systems on the same communication bus, or controller area network (CAN), compromising one system leads to total compromise.

"The car industry has been taking security seriously as they build technology into cars, [but] it's really not car companies' bread and butter to know how to solve various hacks," Fulkerson says.

Embedded systems in cars do not have the benefit of secure programming techniques, address space layout randomization (ASLR), or data execution protection (DEP), which are now common in PC and mobile systems. Combine the lack of historical scrutiny with the fact that a luxury car has some 70 electronic control units and tens of millions of lines of code, and it's a recipe for continued vulnerability.

UCSD's Savage downplayed the current impact of such vulnerabilities, saying the group's research is less an imminent danger and more of a wake-up call.

"The average person doesn't have to worry about this right now -- this James Bond stuff -- no one is doing that," he says. "The place where there is more concern is when you are talking about the surveillance and espionage types of questions."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web