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' infot...@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_ka...@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 _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
