embedded systems security analysis

[goertzel_karen at bah.com (Goertzel, Karen [USA])]

A colleague and I have been looking at the problem a bit, in the context of need for survivability in safety-critical 
systems. Below is an extract of the paper "Software Survivability: Where Safety and Security Converge" authored by 
Larry Feldman, Ph.D., and myself, and presented by our colleague Theodore Winograd at the American Institute of 
Aeronautics and Astronautics' Infotech at Aerospace Conference in Seattle last spring.

There's also a brief discussion of security issues associated with embedded software in the DHS/DACS "Enhancing the 
Development Life Cycle to Produce Secure Software" - specifically pages 272-275. The document is freely downloadable 
after quick registration on the DACS (DTIC's Data and Analysis Center for Software) Web site: 
https://www.dacs.dtic.mil/techs/enhanced_life_cycles/

Karen Mercedes Goertzel, CISSP
Associate
703.698.7454
goertzel_karen at bah.com

--

B.      Embedded No Longer Means Isolated

        Before discounting a comparable threat to embedded systems, consider the following excerpt from Chapter seven 
of Exploiting Software [8] by Greg Hoglund and Gary McGraw: 

        "For no valid technical reasons, people seem to believe that embedded systems are invulnerable to remote 
software-based attacks. One common misconception runs that because a device does not include an interactive shell out 
of the box, then accessing or using ?shell code? is not possible. This is probably why some people (wrongly) explain 
that the worst thing that an attacker can do to most embedded systems is merely to crash the device. The problem with 
this line of reasoning is that injected code is, in fact, capable of executing any set of instructions, including an 
entire shell program that encompasses and packages up for convenient use standard, supporting [operating system]-level 
functions. It does not matter that such code does not ship with the device. Clearly, this kind of code can simply be 
placed into the target during an attack. Just for the record, an attack of this sort may not need to insert a complete 
interactive TCP/IP shell. Instead, the attack might simply wipe out a configuration file or alter a password. 
        There are any numbers of complex programs that can be inserted via a remote attack on an embedded system. Shell 
code is only one of them. Even the most esoteric of equipment can be reverse engineered, debugged, and played with. It 
does not really matter what processor or addressing scheme is being used, because all an attacker needs to do is to 
craft operational code for the target hardware. Common embedded hardware is (for the most part) well documented, and 
such documents are widely available." 

        One of the most widely publicized successful attacks on an embedded system was the 2002 hack of the flash 
memory of the Microsoft XBox game cube in order to access the algorithm used by the game cube?s cryptosystem to decrypt 
and verify its bootloader. [9] 
        Now consider how safety-critical embedded systems?from temperature controls to medical devices to on-board 
airplane and automotive computers and sensors?are increasingly becoming network-accessible. For example, embedded 
software in implanted medical devices is now accessible via radio frequency identification (RFID) interfaces. [10] And 
telemedicine applications in use by DoD enable software-controlled surgical robots located in U.S. military facilities 
in Iraq to be operated via satellite uplinks by doctors at the U.S. Navy Hospital in Bethesda, Maryland. [11] 
        Consider General Motors? OnStar and its less familiar rivals (Ford?s RESCU and VEMS, Volvo?s OnCall, BMW?s 
Assist, Mercedes-Benz?s TeleAid and COMAND). These services all include the ability of call center representatives to 
perform remote telematic diagnostics of the onboard computers in their subscribers? vehicles. The data they collect via 
transmissions from the cars? computers are returned to the remote call centers via cellular or satellite phone links. 
        Remote monitoring and diagnosis of automotive computers sounds benign enough (though there are significant 
privacy concerns associated with some of the data being gathered by these services), but OnStar has gone a step beyond 
simple observation to actual remote control of at least one of the automobile?s safety-critical onboard computers: the 
one that controls its ignition. As USA Today reported in October 2007, [12] the 1.7 million General Motors 2009 
vehicles equipped with OnStar now allow their owners to grant permission for OnStar to cooperate with the police if 
their vehicles are stolen; specifically, if a police car is involved in a high-speed car chase with a stolen 
OnStar-enabled vehicle, the police can request that the stolen vehicle?s engine ?be remotely switched off through the 
OnStar mobile communications system?. The objective of this police/OnStar cooperation is laudable: it allows the police 
to terminate car chases involving stolen vehicles, thereby reducing the number of fatal accidents associated with such 
chases (such reductions are the stated objective of the program), while coincidentally increasing their arrest rates 
and stolen auto recovery rates (not mentioned as drivers for the program). 
        What the new use of OnStar also heralds is a transition of one of the world?s most successful telematics 
systems from passive data collection to active control of remote embedded systems. Imagine a hacker ingenious enough to 
locate, intercept?and tamper with?OnStar cellular transmissions: what potentially disastrous, even deadly, havoc might 
such a hacker be able to wreak by shutting off car engines willy-nilly during a typical New York City rush hour? As 
with so many network connections before it, now that OnStar?s two-way connectivity is there, other potential 
applications are already suggesting themselves, and no doubt at least some of these will prove irresistible. It has 
been suggested, for example, that OnStar could be used to load new firmware into automobile computers without the 
customers having to take their cars into a dealership. Now imagine that capability threatened by the programmer laid 
off from GM who decides to take revenge by hacking into the OnStar call center and inserting malicious logic or even 
just ?garbage bits? into transmission streams over OnStar?s cellular links. [13]
        The question of OnStar?s inherent security vulnerability was raised by PC Today?s ?On the Road? columnist. 
After summarizing OnStar?s and comparable services? security measures (many of which rely on security through 
obscurity) and reporting the vulnerability found in such services by security researchers, the columnist concluded: [14]

        "?auto makers must not relax their diligence, as the future of telematics security is still unclear. In their 
detailed report, Security in Automotive Bus Systems, researchers Marko Wolf, Andr? Weimerskirch, and Christof Paar 
noted, ?[Some] automotive communication networks have access to crucial components of the vehicle, like brakes, 
airbags, and the engine control. Cars that are equipped with driving aid systems allow deep interventions in the 
driving behavior of the vehicle?. Malicious attackers are not to be underestimated.?"

        Do the benefits of network addressable embedded systems and remote telematics outweigh the risks? In most 
cases, probably. But they should also at least raise the question: is the security of embedded systems adequate to 
protect them against direct hacking or malicious code insertion over network connections that they were never 
originally designed to support? This is a question that is relevant for all safety-critical systems that are being 
exposed, to any degree, to access via network connections. 
        Embedded systems have inherently much higher reliability expectations than most of other software systems. They 
are also subject to unique security threats: hackers may use sensitive test equipment to steal, disassemble, and probe 
small devices to remove memory elements from the system to extract their contents. They may use debugging ports and 
software to read sensitive data or force unintended operations. They may measure the device?s electromagnetic radiation 
or power consumption to gain clues about hidden functions and concealed information. They may force the system to 
operate outside its design parameters through introduction of extreme temperatures, voltage excursions, and clock 
variations, thereby exposing anomalous and vulnerable behaviors. 
        Memory devices are a favorite target of attack because they store both the system?s firmware and software and 
its sensitive data. Many such devices can be read while in circuit, and may provide temporary plain text data during 
operation. If the device includes a tamper sensor, the designer can incorporate hardware or software resources that 
will rapidly erase sensitive data before the device can be extracted. 
        Another threat unique to software within embedded systems is reverse engineering of the physical system to 
enable the attacker to devise countermeasures to the system?s security protections, or to the system itself, e.g., 
countermeasures to a weapons system. An attacker might also use information gained through reverse engineering to 
design a new version of the system that can then be used to target the copied system or its originator.
        Embedded software is far more likely to be implemented using any one of a large number of fairly obscure 
(outside of the embedded development community) and non-standard software architectures, languages, and host operating 
systems. ?Security through obscurity? is a dubious advantage of the unfamiliarity and non-standardization of embedded 
software, but it also places a greater burden on each implementer to determine whether the architecture and operating 
system chosen provide adequate security protection or any at all. The proliferation of existing and emerging 
embedded-system architectures is also multiplying the number of attack paths and the number and variety of security 
threats that can leverage those attack paths to cause operational disruptions, to force unintended operations, or to 
extract sensitive data. The same proliferation is inhibiting the development of an industry-wide scheme for security 
protection of embedded software. 
        Some key secure software design principles are particularly relevant to embedded software design:

?       Differentiation between low- and high-consequence functions and public and private data. By denying user access 
to high-consequence functions and private data, the designer can reduce the risks to these elements of the embedded 
system; 
?       The design must provide protection during the embedded system?s normal operation, during attack through a 
network connection, and during electronic probing (e.g., in an attacker?s laboratory). 

        Most specifications for embedded operating system security (e.g., Multiple Independent Layers of 
Security/Safety [MILS], which is supported by real-time operating systems (RTOS) from Green Hills Software, LynuxWorks, 
and Wind River Software) focus on implementing the security protections defined in the Common Criteria. Unfortunately, 
Common Criteria protections, which focus on confidentiality, integrity, availability, and access control of data 
handled by computer systems, and of accountability of their users, do little or nothing to assure the security of the 
software itself. 
        Security concerns have changed the basic design guidelines for embedded products. Traditional criteria for 
evaluating embedded systems designs?smallness of circuitry, efficiency of code, and long mean times between 
failures?are no longer sufficient to assure those systems? dependability, trustworthiness, and survivability. 
Unfortunately, to date embedded system designers have limited their focus on software security protection to preventing 
physical access to the embedded software by strengthening its physical packaging, mainly through use of ?anti-tamper? 
mechanisms.

8. Hoglund, Greg and Gary McGraw. Exploiting Software: How to Break Code (Boston, MA: Addison-Wesley, 2004). For more 
information: http://www.exploitingsoftware.com/
9. Huang, Andrew ?Bunnie?. ?Keeping Secrets in Hardware: The Microsoft XBox Case Study?. Massachussetts Institute of 
Technology AI Memo #2002-008, 26 May 2002. Accessed 2 March 2009 at: 
http://web.mit.edu/bunnie/www/proj/anatak/AIM-2002-008.pdf
10. Becker, T.J. ?Improving Medical Devices: Georgia Tech Research Center Expands Testing Capabilities to Help Reduce 
Potential Interference?. Georgia Tech Research News, 25 July 2006. Accessed 2 March 2009 at: 
http://www.gtresearchnews.gatech.edu/newsrelease/eas-center.htm
11. Ackerman, Robert K. ?Telemedicine Reaches Far and Wide?. SIGNAL, March 2005. Accessed 2 March 2009 at: 
http://www.afcea.org/signal/articles/templates/SIGNAL_Article_Template.asp?articleid= 693&zoneid=128. Also H. Murakami, 
et al., Tohoku University Sendai. ?Telemedicine Using Mobile Satellite Communication?. IEEE Transactions on Biomedical 
Engineering, Volume 41 Issue 5, May 1994, pp. 488-497. Digital Object Identifier: 10.1109/10.293224
12. Woodyard, Chris Woodyard. ?Device can remotely halt auto chases?. USA Today, 9 October 2007. Accessed 20 February 
2009 at: http://abcnews.go.com/Business/Autos/story?id=3706113
13. Note that malicious code deliveries (the most common installation method for viruses, worms) and insertions (the 
most common installation method for Trojan horses) have been involved in several recorded SCADA security incidents. See 
Turk, Robert J., Idaho National Laboratory. ?Cyber Incidents Involving Control Systems?, INL/EXT-05-00671, October 
2005. Accessed 2 March 2009 at: http://www.inl.gov/technicalpublications/Documents/3480144.pdf
14. Farwell, Jennifer. ?Hijacked, Corrupted and Crashed: Does the New Generation of Computerized Cars Pose a Security 
Threat??. PC Today, Volume 3 Issue 10, October 2005. Accessed 14 March 2009 at: 
http://www.pctoday.com/editorial/article.asp?article=articles%2F2005%2Ft0310%2F05t10%2F05t10.asp