White Paper

White Paper
Embedded System Security

Designing Secure Systems with Windows CE
Lawrence Ricci (eMVP) Applied Data Systems Larry McGinnes (CPL) COACT
Abstract
Everyone wants secure systems, and delivery of those systems is a priority with system integrators and OEMs. Whether its a PDA or Smartphone used by a stockbroker, an automation device controlling the power grid, or a remote camera/sensor system for homeland security, security can be central to the device function. CE was a ground up, 32 bit recode of an OS with no legacy DOS code, and Microsoft did include some industrystandard security features. In addition, CEs modular structure allows us to build very tight, locked down configurations quite resistant to penetration, attack, spoofing, and repudiation. This paper will indicate how an engineer can use the requirements based Common Criteria approach to apply the tools supplied inside the shrink wrap of platform builder. We will also indicate third party solutions and system build options that will meet or exceed security standards in effect in many industries and applications.
About the Authors

Lawrence P. Ricci
Mr. Ricci is a Microsoft MVP specializing in embedded system security and currently working for Applied Data Systems in the capacity of Business Development. Before this, Mr. Ricci accumulated 20 years of embedded system experience in control, utility, instrumentation, petrochemical, transportation and other industry/application areas with GE and various ABB companies. He has been active in international business, including formation of the first US Joint Venture in the Soviet Union. Applied Data Systems 9140A Guilford Road Columbia, Maryland 21046 Phone 301-490-4007 Fax 301-490-4582
Larry B. McGinness
Mr. McGinness currently serves as Senior Security Analyst for a Workgroup to define Protection Profile for DISA Anti-virus solutions and as the COACT Manager for Ft. Meade related projects. During his Federal Service career, he consulted with government organizations responsible for developing security policy and products, particularly in the areas of customer support and configuration management as applied to the defense, civil and public sectors.
Table of Contents Abstract.................................................................................................................................... 1 Introduction............................................................................................................................. 3 Devise Countermeasures(people, processes, measures and procedures) .............. 4 Assure Countermeasures Remain Effective- .................................................................... 4 Current State of Security for Mobile Devices....................................................................... 5 Applying Common Criteria to Secure Embedded System Design. ...................................... 7 Setting Objectives ............................................................................................................. 7 Determination of Threat.................................................................................................... 8 Existing, Typical Protections Profiles............................................................................... 9 The Descartes Problem I Think, Therefore I am- WHAT??....................................... 11 Security in a Small Room ............................................................................................... 12 Minimize the build.......................................................................................................... 13 Minimize the ports .......................................................................................................... 14 Extra-Careful Code Review of Drivers and Applications .............................................. 14 Safe Code Throughout .................................................................................................... 15 Traceability and Security of Code During Development ............................................... 17 Omit Needless Data, Encrypt the Rest............................................................................ 17 Security Trail and Audit.................................................................................................. 18 Fast Zero Base................................................................................................................. 19 Security Inside the Shrink-wrap...................................................................................... 20 Summary................................................................................................................................ 20 Figures Figure 1 Simple Embedded Device in Failure Mode From Protocol Attack 5 Figure 2 Cell Phone Having Problems with WAP protocol attack ...6 Figure 3 Chart of Buffer Overrun Attacks over Time...8 Figure 4 Comparison of Threats..10 Tables Table 1: Table of Test Results .................................................................................................. 5 Table 2- Section of Sample Protection Profile ......................................................................... 9 Table 3- Typical Programming Errors.................................................................................... 15 Appendices Appendix 1-Windows CE Security Features .......................................................................... 21 Appendix 2-Various Standards Associated with Security ...................................................... 28 Appendix 3- Table of Contents For An Actual Protection Profile ......................................... 29 Appendix 4- CERT Listing..................................................................................................... 30 Appendix 5- Third Party Windows CE Security Software..................................................... 31
Applied Data Systems 9140A Guilford Road Columbia, Maryland 21046 Phone 301-490-4007 Fax 301-490-4582
Page 2
Introduction
Before embarking on a discussion of security it is necessary to be very specific about what we mean. To some, secure means a stable system, one that does not crash and can be expected to run 24x7. To others, security might mean document management, data traceability, or digital rights management. Security can mean resistance to casual or prankster attacks like most viruses, and security can also mean resistance to DOS attacks. But in this paper, security will mean the embedded devices ability to contain sensitive information and to hold down its end of a secure communication. This type of security is addressed by myriad standards, often specific to industry, country and application. For a short list, see Appendix 2-Various Standards Associated with Security. However, the general movement is towards a common set of standards like CC (Common Criteria Testing, ISO 15408, http://csrc.nist.gov/cc/), FIPS (Federal Information Protection Security http://csrc.nist.gov/publications/fips/). Much of this work is being done by the TCG (Trusted Computing Group https://www.trustedcomputinggroup.org/home). It is vital to understand that security is not attained by inclusion of more acronyms in a system build. Security as defined by CC, FIPS or TCG is a system to: 1. 2. 3. 4. 5. Identify Threat Set Targets Assess Risks Devise Countermeasures (people, processes, measures and procedures) Assure Countermeasures Remain Effective
These five steps are simple common sense. In the context of an embedded system - say a PDA - they might be exercised as follows:
Identify ThreatBecause the device is mobile, it might be lost. If it contains sensitive material, a unfriendly party might be able to steal the information or even use the PDA to log into a secure network and spoof the user.
Set Targets
Targets could be set at various levels- for example Render the devices safe from unsophisticated attacks such as dictionary attacks on the 4 digit passcode or an attack with a stolen passcode. Render the device safe from sophisticated attacks such as might be made with a logic analyzer, bed of nails tester, and powerful code-cracking computers.
Page 3
Assess RisksRisk is determined by what the effect of penetration would be. For US Government operations, the following terms1 are used: TOP SECRET- .. unauthorized disclosure .. could cause exceptionally grave damage to national security. SECRET- .. unauthorized disclosure .. could cause serious damage to national security CLASSIFIED- .. unauthorized disclosure .. could cause damage to national security
Devise Countermeasures(people, processes, measures and procedures)

Many options exist: Make sure any data stored on the device is stored in encrypted form, unlocked only by a sufficiently long key known only to the authorized user. Use three element Biometrics (fingerprint), token (Machine readable ID card) and password to verify authorized use. Provide intrusion detection (monitor for dictionary attacks, case open, etc) and have a self-destruct capability for the device or at least the devices data. Some combination of the above
The options selected will depend on the sensitivity of the data.
Assure Countermeasures Remain EffectivePeriodically audit the devices defensive capabilities and the users operation- e.g. does he change his private password often enough. This very brief example of one threat and possible countermeasure is presented only as a hypothetical and does not (in our knowledge) reference any accepted Security Target or Protection Profile.
Refer to Executive Order E.O. 12958 Section 2-10, items a, b. It should be noted that this is the ONLY official classification system for information. However, the term SBU (Sensitive but Unclassified) has come into general use to refer to items like a diplomats schedule.
Page 4
Current State of Security for Mobile Devices

The threat certainly is real. Doctor Markko Lasco of Oulu University, Secure Programming Group in Finland2 has published a series of tests run in the year 2000 on various cell phones and other mobile, networked devices (apparently none of them Windows CE). He has seen the following, somewhat alarming result.
Table 1: Table of Test Results PROTOS test-suites - vulnerability assessment through syntax testing
Table one
Test-suite c04-wap-wsp-request c04-wap-wsp-request c05-http-reply c06-ldapv3 c06-snmpv1 Failed products 7 (7 tested) 10 (10 tested) 5 (12 tested) 6 (8 tested) 12 (12 tested) Failure Rate 100% 100% 42% 75% 100% CERT Advisory n/a n/a n/a CA-2001-18 CA-2002-03
[http://www.ee.oulu.fi/research/ouspg/protos]
In spite of the indicated device vulnerabilities, in the Wild as of December 2003 there have only been about 4 cell phone virus-like attacks (all on simple text-messaging cell phones), and 3 virus or Trojan attacks on Palm. There have been no confirmed virus attacks on PocketPC or a Windows CE device. Clearly, the relative peace and calm we enjoy in the mobile environment is not because of the security within our devices. This peace is ominous, and based on experience with other peer-to-peer environments, undeserved. Most of the nasty and disruptive virus attacks on desktops and servers have been the products of second rate programmers looking for attention from the community or their immediate peers. They find out how to make a virus only when a professional finds the vulnerability and issues a security patch. The hacker then figures out an exploit based on the patch. But this all happens within the desktop/server environment. The threat we will face in the embedded/RISC space will come from professionals, well funded, able to buy sample target devices, and able to find and co-opt sympathetic agents within our enterprise. We
Figure 1-Simple Embedded Device in Failure Mode From Protocol Attack
Dr. Markko Lasco of Oulu University, Secure Programming Group http://www.ee.oulu.fi/research/ouspg/index.html
Page 5
can assume these adversaries will pose specific threats, not in our interest, and will be more likely to develop covert Trojan/Backdoor exploits than dramatic, public viral displays of their prowess. Indeed, one of the cell-phone attacks has been reported (but we have been unable to confirm details) to create a DOS attack on Houston 911 emergency service. If launched at a certain time, coordinated with terrorist attack, this could have been devastating. Also, while not strictly a software hack, a recent terrorist explosive device was triggered by a cell phone. While this might be considered more of a misuse than an exploit, it would be possible (and at very low cost) to make a cell phone that would be very difficult to hotwire into a remote control. We favor a simple starting point: A threat is a threat; if we know an embedded Figure 1-Cell Phone Having Problems with WAP system could be misused, we should consider protocol attack counter measures. So far, political or criminal hacker attacks have relied on standard desktop and laptop hardware and occasional theft of Internet access via open 802.11 hot spots. However, attacks and exploits on embedded devices are starting to get attention in the hacker community. Exploits against PDAs were a featured and well attended program at the 2003 Defcon (http://www.defcon.org/). Also, there are now Cell Phone Hacking tools available on the net from the community, as they call it. There is a lot at stake embedded systems are carrying an ever increasing amount of our communication, controlling our electrical system, water system and the cash machines for our currency distribution. Indeed, most expect embedded systems to be an important part of our homeland security apparatus, for communication, materials tracking, remote cameras and sensors, etc. It is pretty frightening to think of some event that would raise the profile of embedded security to the point where the average man on the street could properly use the terms embedded system and exploit in the same sentence. The component/system professionals need to get ahead of the curve.
Page 6
Applying Common Criteria to Secure Embedded System Design.

Security is best obtained by a systematic approach. We start by establishing some goal for the overall system, whether it is a PDA/cell phone or an embedded control/monitoring system. Then we identify threats, both active/historic and theoretical/ possible. Next, we develop our objectives for the system usually based on the importance of the data were protecting. Finally, we identify countermeasures to protect against each threat and meet the objective we set for security. This process, contained within Common Criteria, may be mandatory for certain government systems. But even for a commercial, self-certified OEM design, this is still the best approach.
Setting Objectives
To design a secure system, we need to first establish security requirements via what is called a Protection Profile. This starts by determining objectives: exactly what do we want to protect, and what is its importance. For example, the schedule of a diplomat might be given the unofficial classification Sensitive but Unclassified. Something that could damage national security could be deemed CONFIDENTIAL and require EAL Level 2 protection. Information that could cause serious damage to national security would be and classified as SECRET may require EAL-Level 4 (Medium Robust) security. Higher security levels like TOP SECRET are used for issues that could cause exceptionally grave damage to national security. . While most of us designing systems like ATMs, automation controllers and PDAs will not have to deal with the higher levels of security, any engineer developing systems can set his objectives in line with the CC/FIPS nomenclature. Some information is unclassified, or public. Other information is sensitive (e.g. compromise could be embarrassing, cost a manageable sum of money, or require extra work), and still other information, if compromised, could have grave consequences- for example bring down part of the power grid, input incorrect targeting coordinates to a weapon, etc. While the common criteria does not directly address or correlate to the US Government information classification system, it does translate to roughly equivalent assessment and reduction of risk in the US Common Criteria Schemes i.e. low, medium and high robustness.
Page 7
Determination of Threat
The next step is to classify threats- which are of two general types. Theoretical Threats or In the Wild Threats. Theoretical threats are typically found by universities and vendors. In the Wild threats are exploits actually in use. When reported, these are recorded by organizations like the government funded CERTs at Carnegie Mellon university (http://www.cert.org ) and other places, or the industry association SANS Institute (http://www.sans.org) . These same organizations also tabulate threats in the wild and assign potential levels of risk to the threat. These two organizations provide good, objective data on vulnerabilities of various systems. The reader is encouraged to look at a typical report as seen in Appendix 4- CERT Listing. These organizations also keep track of historic activity. There is no need to use rumor or gossip to establish a threat. They are well known.
Figure 2 Chart of Buffer Overrun Attacks over Time Attacks exploiting Buffer Overruns are important because they (a) may be linked to protocol, not just implementation failures and (b) they are the most typical way of implanting Trojans
Frequency of buffer overrun vulnerabilities, derived from a classification of CERT advisories. The left-hand chart shows, for each year, the total number of CERT-reported vulnerabilities and the number that can be blamed primarily on buffer overruns. The right-hand chart graphs the percentage of CERT-reported vulnerabilities that were due to buffer overruns for each year.
Threats in the wild can also be identified-albeit at lower confidence- on the myriad hacker sites where the hacker community post each occasion of their vandalism so they can keep score. The matrix within the Common Criteria of Threats mapped to Security Objectives is the start of what is called a Protection Profile as seen in.Appendix 3- Table of Contents For An Actual Protection Profile Each element of this matrix describes the requirements for a technique, device or procedure to counter that particular threat at the desired security level.
Page 8
Existing, Typical Protections Profiles

A Protection Profile has already been created for Server and WorkStation systems and the necessary features and countermeasures for different threat levels have been defined under Common Windows server 2000 has been qualified at EAL-4, which can be adequate for storage and Table 2- Section of Sample Protection Profile communication of US Government SECRET data. This THREAT OBJECTIVE is a level of testing shared by 1 T.ENTRYAn individual, other than an Prevent first tier intelligence certain versions of sun Solaris, SOPHISTICATED authenticated user, may gain services from accessing data, HP UX and some other systems. access to the PDAs processing even at the cost of device and One version of Linux, SUSE has resource or information using a data destruction been tested to EAL-2, and the sophisticated technical attack. NSA has provided some sample 2 T.OVERLOAD Overload of the PDA by Prevent overload by taking code to the Opens Source excessive network traffic network port off-line as the exceeding amount permissible PDA becomes heavily loaded. community for Secure Linux. How does this existing desktop/server Protection Profile map to the embedded space? Can we apply all these same threats, objectives, assumptions and countermeasures to PDAs, automation controllers, etc? The answer is probably no.
by the PDA may allow malicious code to enter the network. Disconnect safely from the network, advising other linked systems you are signing off
3 4
Etc. Etc.
The Hostile Hands Assumption.
Desktop/Server Protection Profiles make the stated assumption called Enclave Integrity.
The communication between the Target of Evaluation and users operates within a controlled access environment that provides protection against unauthorized access
The traditional workstation/ server protection profile assumes the device is in some sort of controlled environment, and tended by generally trustworthy individuals. When dealing with a mobile device, the only reasonable assumption is that it WILL fall under the control of a hostile party. We do not have to wait until a device is lost. Very shortly after a new secure device is known to exist, we can assume that hostile hands will either steal one, kidnap its user with the device in his pocket, or spirit the device away for overnight examination while the user sleeps.
Obviously the threat level for a mobile device is high, but it can be met. Technologies (both hardware and software) exist to mitigate all of the above risks. Once we recognize and accept this, we can begin to design secure PDAs, Smart Phones and other mobile and embedded devices. These devices must maintain one end of a secure communication link, and could even store certain data. But special care
Applied Data Systems 9140A Guilford Road Columbia, Maryland 21046 Phone 301-490-4007 Fax 301-490-4582 Page 9
must be taken. For example, a device should have the ability to determine if it is being attacked- including attacks with a screwdriver and logic analyzer, or even with a radiation chamber looking for data superimposed on RFI emissions. The device possibly could contain some sort of self-destruct mechanism like the crypto units on military planes. The device should almost certainly contain features to help it destroy any data it carries. This implies some deep linkages with OS code and hardware. Further, Embedded Systems can be expensive to clean if compromised. Remember, a system can be compromised without being touched. A remote device using Crypto-X is compromised if some adversary managed to break or steal Crypto-X in another location. This may require new FPGA programming - hard to do on site.
Figure 3 Comparison of Threats
Portable and Fixed Environment Portable Device Secured Workstation

A highly trusted but rogue user, who knows the undocumented features and internal design of the device, and with access to other peoples public and private keys decides to steal data he should not see, or spoof someones identity to insert misinformation A trusted user with a device falls into a situation where he is under extreme pressure from an unfriendly party His fingerprint is removed along with his finger, or a counterfeit smart card with someone elses fingerprint is made with the intent of defeating the biometric The device can be put into a reflecting metal chamber, equipped with sensitive RFI/EMI detectors, to monitor data streams superimposed on the EMI emitted from the device. This chamber might even be disguised to look like a hotel room, coffee shop, or other place where the user might employ the device. The device, SmartCard ID and password fall into the hands of an unfriendly party, and then returned, without us knowing they were gone- (e.g. nighttime hotel room theft) This scenario must be anticipated and fully expected. It might be possible to exploit this expected theft by passing disinformation in outer layers of lightly protected sections of the system. The device, card and password fall into the hands of an unfriendly party, and we know it. The rogue user would probably have to work at the terminal of the person whose information he wanted to steal or who he wanted to spoof. Even if he were working on another secured terminal, he would still be subject to surveillance and his actions logged. Not Likely- they might kidnap the person, but not the secured terminal where he works.
Extremely unlikely
Extremely unlikely
Extremely unlikely
Page 10
Secure Embedded System Threat Assessment and Possible Countermeasure

Some of the required techniques required for robust, secure implementations of Windows CE follow. Remember- these techniques are general good practice only. The merit of these techniques must be measured against an appropriate Protection Profile for the device.
The Descartes Problem I Think, Therefore I am- WHAT??

The TCA quickly realized that no software alone can either (a) verify it has not been changed or (b) verify it is on the correct piece of hardware. This is important for server/desktop systems, but is vital for mobile systems. A mobile system, remember, WILL fall into Hostile Hands who could take it to a lab and try to (a) insert new software or (b) take the software and data out and run it on another platform. In a secure configuration, all software must be branded at birth. The way this is done is to create an indicia (simplistically a check sum) of the software as it loads through the bootstrap. This, combined with a hard, non-erasable serial number on the device, forever identifies the software and hardware to each other. Once this marriage is established, a chain of authentication begins with the bootstrap authenticating the OS and the OS authenticating the applications and the applications authenticating data, user and network connections. It goes without saying that for most definitions of a secure Windows CE device, the code signing available in CE.NET should be used rigorously and everywhere. This signing process should be traceable back to the initial boot and run of the OS.
Page 11
Security in a Small Room

The PDA/Cell phone is quite different from a Workstation/Server in another way. They are single user systems- not one user at a time, but one user. This makes things both easier and harder. Things get easier because many of the CC threats and countermeasures for desktop/server systems deal with multiple users, and different security levels, on the same system, perhaps concurrently. Tremendous constraints are placed on the operating system to prevent information from going from a high level security to a low level security, while still allowing information to move the other way. This is not just file transfer; clipboard and even screen print must be disabled to prevent wrong-way information flow. The information leak issue still exists in a single user system - for example, we may want to counter the threat of a Rogue User who would want to obtain high security information through one session with a secure server, and then pass it on to a confederate during a low security session, with perhaps a public ISP. But even so, the single user constraint makes the problem more contained and easier to solve and audit. However, the single user assumption complicates the situation in another way. The environment is typically Peer-to-- Peer by design, incorporating the risks associated with that premise. In a PDA, the User and Administrator are typically the same person. Both can access the control panels. With as many System Administrators as PDA owners, enterprise configuration control goes out the window and the PDA becomes an un-recorded point of access at the edge of the enterprise IntraNet. Still, this process goes on in many companies, perhaps because 80% of all PDA;s are bought with the employees money and are considered free assets by the employer. But if we want, access to administrator functions can be controlled in various ways. First, with Windows CE, you do not have to put the control panels in at all. Parameters can be adjusted by a custom programmed, password protected, special administrator function. Alternately, there are third party solutions 3 that will lock down any program (including Control Panels). Perhaps the best known third party product for this was developed by Odyssey Software and is currently distributed by Symbol technology as AppCenter For PPC2003 there are many options listed in Appendix 5- Third Party
Windows CE Security Software.
Second, you can design a application that lets the network take control of the PDA when it is attached to the enterprise. This control can be very strong, and limit the PDA to a viewer of controlled data. Further, Flash Bomb subroutines can be installed in the OS to blank all data and overwrite to destruction sensitive data in Flash Memory if the PDA is tampered with. 4
3 4
See Appendix 3 For a List of PPC and Windows CE 3ed party Software Suppliers Trust Digital implement this technique in their Trusted Mobility Suite. Elements may be patent protected.
Page 12
Minimize the build.

Any piece of software, especially communication software, is a potential point of attack. Windows CE is completely modular and the designer should be very sure that no software is included unless it is needed by the application. This means that with standard or packaged BSP builds, as might be provided with a development system or low cost COTS. Single board computers should be considered security hazards. The tendency of the development system supplier is to put every possible feature and option into the operating system image to minimize requests for new features and functions. In particular, CE.NET can be configured to do as much or as little as you want. Unless needed by the specific application, code should be left out. This is especially true for communications functions like the Web Sever, FTP Server, RDP, SMTP, Telnet and of course, Active Sync. If these programs were co-opted by a Trojan, the result could be very bad. Also, prune back the application level support if you can. SQL, VB support, and FCMs may not be needed, yet they represent a large stack of code that can be attacked. Also, just because a UART, CF, PCMCIA, USB or other communication port is not installed on the board does not mean that the driver can be left in the OS build. A mobile or embedded device could come into the possession of a hostile party with enough technical insight to yellow wire a communication chip in place and to use the undefended port to penetrate the system. When selecting what application environment to build into the system, the engineer might want to consider managed environments and languages developed by Microsoft after the Trustworthy Computing Initiative was underway. In particular, we would recommend C# or VB running in the CF. Not only was this code subjected to more rigorous review while still young, but a managed code environment like the CF can do a lot to minimize buffer overflows. This is particularly? important because while buffer overflows are very common exploits, they are by far the dominant exploit used to insert Trojans. Remember, for embedded systems, a stealthy Trojan is a more likely and serious exploit than a very public virus pledging its love for you.
Page 13
Minimize the ports

Any port into the system is a potential point of attack. Apart from the obvious communication ports, the developer should consider test points built into the system for its manufacturing and test cycle. In particular, JTAG emulation, as supplied with most current RISC CPUs, could allow a hostile party in possession of the device the ability to assume very complete, direct and overriding control of the CPU. Access to this point needs to be securely locked down with hardware and firmware before an embedded device is deployed.
Extra-Careful Code Review of Drivers and Applications

One typical form of attack is to overload a driver so it backs up and fills its local buffers and memory tables and starts to put information on the operating systems stack. Then malevolent code can be pushed onto the stack. When the stack unloads, the code can be executed and can transfer control of the system to an external entity. This is potentially a very serious exploit since it attacks right at the register and program counter level. Once through the stack, an exploit can jump to any region of memory and run code, bypassing the code-signing process. Future generations of CPU (such as ARM-11) and upcoming Pentiums will have hardware protection that will trip an interrupt with any attempt to access secure memory. But for now, we must either build in external hardware protection using FPGAs on the CPU bus or be very sure that external attack will not cause an overflow. Many commercial drivers, even ones used in hundreds of thousands of PDA and laptop applications may not be stable enough for a secure system. Laptops and desktops are frequently shut down allowing the drivers to purge their reserved memory. Commercial PCMCIA or CF cards are plugged in and out often, flushing the buffers and resetting the driver. Embedded systems are expected to run 24x7. Even PDAs, when shut off are not really off, but in a sleep mode where the software is in place but quiescent. Drivers need to be stress tested over long time intervals (days and weeks) to verify no leaks. Finally, there are some high security plug-in cards and USB security fobs with drivers which although well audited and tested on laptops, exhibit certain problems when recompiled and run on RISC instruction set computers. If you have had to interface to one of these, you know what I mean. . Once your own code review is done, you will have to prove it to the evaluators. Common criteria evaluators review vendor generated tests/reports. At higher EAL levels, the approving agency may require their own source code review. There are also various independent test labs that will develop their own tests, in turn evaluated by NAIP at the higher assurance rating. Depending on the assurance level, the vendor may have to expose part or all of his source code for review.
Page 14
Safe Code Throughout

Throughout the system, and especially at the driver level, code should be reviewed for techniques to help it resist exploits. Juha Roning of University of Oulu5 has compiled an excellent list of programming errors that he has found caused security breaches in embedded systems. Table 3- Typical Programming Errors Along with these in Error! Reference Oulu University Secure Programming Group Chris Tackes Comment With Respect to (2002) Common Errors CE.NET Embedded System source not found., we 1 Buffer overflows have placed comments -- The memory reserved for a buffer or a variable can be Buffer overruns are still quite possible in CE. Managed by Chris Tacke, exceeded and the program can write outside this code makes this difficult to do unintentionally, but it is a memory (in the stack or in the heap) common bug in unmanaged code. Be careful, very eMVP, on the -- Most common vulnerabilities, very common in lowcareful, with the drivers. relevance in the level languages 2 Memory allocation bombs CE.NET environment. -- Embedded systems usually have very light weight CE definitely has this problem. The memory model for Chris, the author of memory management in their operating systems: the processes actually swaps data in and out of slot Programming Visual Processes may share the same memory space and the zero. Large (>2? MB) data blocks must be allocated in memory allocation function of the operating system shared memory, which exposes the memory to Basic and 300 could wait until a block big enough is free or fail instantly potential attack or accidental modification. posts/month on if a memory block big enough is not available. 3 Recursive parsers Microsoft Forums has -- Embedded systems usually have a rather small I'm not sure of the stack depth, but recursive perhaps the dubious stack, where registers and function call return programming is rare in the embedded space and honor of fixing more I've not seen it as an issue ever in CE addresses are saved. This will cause recursive parsers to fail, if it is possible to force it to do a deep bad code than anyone level of recursion. else in the CE 4 Signed indices or lengths community, so he -- Values used in table look ups and length Not sure what happens if you provide a negative knows a great deal comparisons should be unsigned. However, index - I've never tried it. programmers are often using signed data types. about the errors Negative indices and lengths are sure to cause people make. problems.
5 Format string vulnerabilities
-- Caused by incorrect usage of printf()-style functions -- Fairly common and serious flaw
A common problem, yes
6 Missing checks for missing elements -- An application receiving information from the parser might crash due to a missing mandatory element it expects to be always present. This might also result in accessing illegal memory areas. 7 Too small data types - might cause an infinite loop due to roll-over
The compiler catches missing parameters long before execution
The embedded system developer should focus closely on the issue of buffer overruns. We have mentioned this before, and will mention it again.
Perhaps years of coding for desktops that are shut down 8 Missing integer boundary value checks every day and flush -- Missing a check could result in reading data Never tried it. Intuition tells me the compiler will their buffers has made located after the end of a table, thus resulting in complain about this. access violation (denial of service) programmers lazy. By Murphys law, the Buffer Overrun is especially dangerous in the embedded system
This can happen and is sometimes intentional or at least accounted for.
5
Software Considered Harmful: Why Software is Insecure Juha Roning http://www.ee.oulu.fi/research/ouspg/protos/sota/CorpSec2002/index.html
Page 15
because it can be used to insert a Trojan, a more likely form of attack than a prankster virus. In any case, these faults are very hard to find. Indeed, of six modem drivers tested by Applied Data Systems in 2003, three had memory leaks. All of these were from top tier respected vendors. The problem is tough, I quote here an excellent paper by Mark E. Donaldson, published by the SANS institute:6 Problematic buffer overruns related to the C programming language data integrity model were first recognized as early as 1973. The first well known exploit of this vulnerability occurred in 1988 when the well documented and infamous Internet Worm shutdown over 6,000 systems in just a few short hours, utilizing an unchecked buffer initialized by the gets() function call in the fingered daemon process. Despite this lengthy history and simple preventative methods, the buffer overflow continues to be a significant and prominent computer security concern even today. For example, buffer overflow problems are implicated in five of the Sans Top 20 vulnerabilities. If one ventured to the SuSE Linux Web Site, they would find 22 buffer overflow vulnerabilities since January 2001 [ to April 2002] that require patching. Additionally, of the 44 CERT advisories published between 1997 and 1999, 24 were related to buffer overrun issues. Programmmers today are not usually in the habit of finding errors in the syntax of their C complier, but that is the mandated reality of development in the embedded space.
INSIDE THE BUFFER OVERFLOW ATTACK: MECHANISM, METHOD, & PREVENTION Mark E. Donaldson http://www.sans.org/rr/papers/46/386.pdf
Page 16
Traceability and Security of Code During Development

The general assumption should be that if a secure device is put into manufacture, there will be an attempt to penetrate the supplying organization and install backdoor code. To this end, code development needs to proceed in a locked down environment. For example, how do we know the Platform Builder were using has not been tampered with or compromised in some way? Even if downloaded from a corporate site over secure FTP, is the content trustworthy? This is not idle speculation; it is a vulnerability that has appeared In the Wild of the Linux community7. Even internally, within the organization, as code is passed from one developer to another, the transfer of custody needs to be verified and controlled. And of course source and object code modules need to be stored in secure locations, encrypted, and backed up according to approved procedures. The code produced must be clean; during development programmers typically install breakpoint code to monitor operation and jump out of the code stream. This must be removed from final source code, not just commented out. Remember too, the BSP (Board Support Package) of an embedded system includes a bootstrap and loader, equivalent to much of the standard BIOS of a x86 desktop or server. Security and traceability of this code is the most important. As this is the point where an exploit can enter and disable all other code signing security features. The absence of backdoors and other flaws must be verified. In the US, the Common Criteria validators within the NIAP oversight organization believe independent review of source code, under non-disclosure, using the most sophisticated techniques, is required to obtain the higher EAL ratings. At the highest security levels a full code review of the operating system may be required. The windows shared source agreement allows for this review.
Omit Needless Data, Encrypt the Rest

This is a very important point. The best way to secure data is not to have any that needs securing. It may be possible to develop your application where secure data is handled with a client/sever model and only in the embedded device while it is being looked at. But how the browser or RDP (Remote Desktop Protocol) is implemented, makes a difference. If a browser or RDP client is used to access a secure system data may persist even after the secure connection is terminated. The data may reside in the browser cache or elsewhere. This must be eliminated by configuration or special code. For a secure system development, we should obtain a memory image of the device to verify there is no residue data.
Devil in the details - why package signing matters Kurt Seifried, kurt@seifried.org 2001/10/24 http://www.seifried.org/security/articles/20011023-devil-in-details.html
7
Page 17
Remember that not only the content is classified or secret information. The user names, IP addresses and of course passwords may persist after logging off. These need to be purged explicitly in the log off procedure, including log offs for errors, disconnects and security violations.
As an aside, standard practice on desktop systems is to encrypt all data on disk, and to erase data with a minimum of seven over-writes to the disk. What does that mean for an embedded device where there typically is not disk? Certainly, encrypting data in flash makes very good sense. A failed device, with almost any security, could leave its flash memory exposed to unauthorized access. Also, even data in memory might best be encrypted. Many PDA devices use DRAM data files as disk storage; the data persists in memory during sleep mode. It is possible to consider some form of hardware/software penetration that might render the data visible. There are third party packages (see Appendix 5- Third Party Windows CE Security Software) that facilitate encryption of data in the device
Security Trail and Audit

One powerful form of intrusion detection has been review of system logs and events. Unfortunately, most embedded operating systems, like Windows CE, do not log events. This can be fixed however. A short event logging routine can be installed in every application process and even most system processes to post a time and event log, encrypted file in some protected piece of memory, and then transferred upward. For embedded applications (for example automation), where the application itself is very much a user, these functions might best be included with the administrator functions and managed as part of the on-line connection process, probably uploaded to the server.
Page 18
Fast Zero Base

An embedded device should be able to destroy its memory very quickly. If attacked (for example, a dictionary attack on password) the device should be able to blank any sensitive data. This can be done in many ways, even on a hardware-stock Pocket PC. Upon detection of attack, the device can be programmed to (a) ignore its on/off command and to (b) repeatedly write to flash memory until the memory is blacked. Be careful however. Modern Flash Memory is rated for many rewrites and this, combined with the slow write time for flash, means it could take a long time to zero base. Also, the Flash Bomb routine to do this needs to understand the memory management and load leveling provided by the systems flash-file manager and needs to make sure it is targeting the actual cells on the chip with the critical data. The ultimate way to zero-base a device is to forgo flash and use only RAM with battery backup. With modern super cap technology, this is quite practical, and even allows for battery changes and power interruptions. RAM can be dumped in an instant, by either software or (better yet) hardware techniques. Finally, there is some data that cannot be easily erased. This is the secure ID for the device. This must be stored in memory that cannot be overwritten, otherwise the device could be spoofed by another device which has been recoded. Further, if nothing were recovered except this code, it might be possible to rebuild a new device with hardware backdoor, and reload the fake device with good, but now compromised, software. There are hardware methods and techniques to make even this device ID self-destruct if the device comes under the control of hostile hands. Also, remember that even if a user says he keeps no sensitive data on his PDA, he probably does. Your companys wireless SSID, channel, and WEP pass phrase are all there, and unencrypted. Your usernames, IP addresses, domain names, and passwords may be visible. Indeed, most of the information needed to crack your companies network is in a PDA, either as configuration information, or perhaps as the users personal list of passwords.
Page 19
Security Inside the Shrink-wrap

There are many security tools, protocols, encryption etc. that can be used to meet a Protection Profile. Windows CE contains many of these in its standard distribution. Further, it has been built with hooks to work as a platform for a variety of third parties who supply add-on tools and techniques. The table in Appendix 5- Third Party Windows CE Security Software includes some of the most often requested security techniques that are included in Windows CE, with a reference to a third party if there is a need for one. Remember, all this is inside the shrink-wrapyou do not have to go and find it, compile it for your CPU and libraries, link and test it. Likewise; all this is supported in Platform Builder and Visual Studio, a very powerful IDE (Integrated Development Environment) PocketPC is a special case, one where special hardware features may not be easy to create. Even so, there is much that can be done to maintain a level of security. For configurations of the Pocket PC or CE.NET configured close to the Pocket PC, the reader is advised to consult Chris De Herrera's Windows CE Website8
Summary
Whether we look at the problem top-down or bottom-up, good practice is mandatory for secure system design. Good practice for embedded system design deals with both hardware and software elements. Bottom line- seriously and thoroughly addressing these issues cannot be done sitting around a circle in a room, generating great solutions to problems that may or may not exist. Embedded System Security requires a methodical documented approach of identifying the threat and mapping countermeasures and then verifying their effectiveness through a recognized process like Common Criteria.
Copyright , Applied Data Systems, Inc, 2003-2004. All Rights Reserved. This document may not be used for commercial gain without permission of Applied Data Systems, Inc. Any trademarks used within are the property of their respective owners. This document contains technical descriptions that may not be representative of Applied Data Systems product or services
Chris De Herrera's Windows CE Website (ttp://www.cewindows.net/reviews/pocketpc2002security.htm)
Page 20
Appendices
Appendix 1-Windows CE Security Features
Topic
Networking WEP Support
Meaning
Does the product offer support for Wireless Encryption Protocol?
Supplementary Data, Comment

40-bit and 104-bit WEP Encryption strengths. Be careful!! This can be broken.
WAP Support
Does the product offer support for Wireless Application Protocol?
Consult work by University of Oulu, PROTOS project. There appear to be syntax problems with WAP itself that preclude secure operations
802.1x Support
Does the product offer support for 802.1x authentication?
The following EAP Authentication methods are supported: EAP-MD5, EAP-TLS, EAP-PEAP. A 3ed party, Fortress Technologies, offers FIPS-140 certified link level security.
VPN Support
Does the product offer support for any Virtual Private Networking technology?
PPTP and L2TP/IPSec available for both client and server
EAP Support
Does the product offer EAP authentication?
Supports following extensions of EAP: CHAP, TLS, PEAP, MS-CHAP v2.0, MD5 CHAP
PPP Support
Does the product offer PPP authentication protocols?
PPP supports the following authentication protocols: PAP, CHAP, MSCHAP v1 and v2, EAP-TLS, PEAP
PPTP Support
Does the product offer support for Point-to-Point Tunnelling Protocol?
Differences between CE and XP's implementation of PPTP can be found at: http://msdn.microsoft.com/library/enus/wcevpn/html/ceconDifferencesBetweenWindowsCEWindowsXPPPT PImplementations.asp
L2TP Support
Does the product offer support for Layer 2 Tunnelling Protocol?
L2TP/IPSec (client and server) support for VPN only. Certificate, preshared keys, Internet Key Exchange (IKE) protocol supports authentication and key exchange using Diffie-Hellman. Based on .NET Server code.
IPV6 Support
Does the product offer support for Internet Protocol version 6?
The complete list of supported RFCs can be found in MSDN: http://msdn.microsoft.com/library/enus/wcemain4/html/cmpssipv6rfcsinternetdrafts.asp
IPSec Support
Does the product offer support for IP Security Protocol?
End-to-end IPSec for IPv4 based on .NET Server 2003 code. Full policy support is not included; built hooks exist to add.
Page 21
Appendices
Topic
Firewall Support
Meaning
Does the product offer firewall support?

Packet Filter that allows user to define rules to filter IP traffic. Details available at: http://msdn.microsoft.com/library/enus/wcetcpip/html/ceconIPFirewall.asp
Device Management / Update Patch/SP Installer Does the product offer Support an installer for patches and service packs?
Wceload.exe and CAB files generic software installer. MS cab file format supported. Described in MSDN. Packager cabwiz.exe ships in eVc. 3ed provide CAB files that deploy the required software in the specified location on device. Please note that this is NOT patch specific
Patch/SP Deployment Support
Does the product offer support for the deployments of patches and service packs?
CE Device Management Framework can download any specified patch. Requires SMS 2003 Value Pak. 3ed parties like Rapport Technology offer network wide remote management capability.
Patch/SP Scanning/detection Support
Does the product offer functionality that scans for missing patches and service packs?
CE Device Management Framework can detect presence of software/version and report back to management framework via a software inventory report. SMS 2003 value pack adds support for CE devices and can find this information from a software inventory report
Application Deployment Support
Does the product offer functionality for managing the deployment of applications?
CE Device Management Framework provides support for Application deployment. Requires SMS 2003 Value Pak
Policy Support
Does the product offer functionality for disseminating, managing or enforcing policies to users or machines?
Custom policies can be implemented by admin using the CE Device Management Frameworks script engine. (eg modifying rag keys, deleting files, rebooting etc) Custom scripts via SMS 2003 (.dms files)
Remote Installation
Can the product be remotely installed?
This feature is offered by a 3ed party, Rapport Technologies
Remote Deactivation/Device Kill
Does the product support any means of remotely deactivating either the product itself or the device it runs on?
This is typically a custom HDW/SFW feature. It is relatively easy to 'zero' a device by flushing RAM and or overwriting Flash to destruction.
Page 22
Appendices
Topic
System Software (flash ROM) partial updates
Meaning
Does the product offer partial (differential) updates for ROM ?

This is a function of the FFM (Flash File Manger), typically supplied by Datalite, Intel or mSystems. All of these support partial update, at least at the sector level. Note that a FFM will typically dynamically map sectors to various physical regions of Flash to 'level" load. Sections of Flash can be reserved for direct addressing and used the storage of keys, addresses and various crypto data. These can be updated, direct to memory location, by custom BSP code.
Full ROM update
Does the product have a (full ROM) code updated to a new image from a website?
With third party software like Rapport, the entire system image (less the bootstrap and a small client) can be updated via TCP/IP over a web link.
Authentication / Cryptography Encryption Support Does the product offer any features for encrypting or decrypting user data?
RSA, DH, RC2/4/5, DES, 3DES, AES. Hooks available in the OS to allow others to write Encryption Filters (no native encryption support in File system). Also supports 3rd party Cryptographic Service Providers. Including Fortezza and FortezzaPlus
Digital Signature Support
Does the product offer any features for signing data and/or verifying signatures on user data?
DSA, RSA. CryptoAPI 1.0 for signing.
Hashing Support
Does the product offer any features for hashing user data?
SHA-1, SHA-2, MAC, HMAC, MD2/4/5.
Cryptographic API Support
Does the product offer any cryptographic API sets?
CryptoAPI 1.0 is virtually identical to desktop. CryptoAPI 2.0 APIs supported in CE can be found at: http://msdn.microsoft.com/library/enus/wcecryp2/html/ceconSupportedCryptoAPIversion20APIs.asp
NTLM Support
Does the product offer NTLM authentication?
Client Auth: LM, v2; Client Session: v2; Client Connection and Datagram support Server Auth: LM, v1, v2; Server Session: None; Server Connection support only, no datagram. NTLMv2 is compatible but not identical to XP. Signing/Sealing only with NTLMv2.
Kerberos Support
Does the product offer Kerberos authentication?
From Win2K. No PKINIT support. No change password. Limited server side support (no PAC decoding). Source code available from MIT; can be integrated.
SPNego Suport
Does the product offer SPNego authentication?
Support similar to WinXP
Page 23
Appendices
Topic
S/MIME Support
Meaning
Does the product offer support for Secure MIME?

3ed parties provide S/MIME function for PPC and WindowsCE
SSL Support
Does the product offer support for the Secure Sockets Layer protocol?
SSL 1.0/2.0/3.0, TLS 1.0.
Passport Support
Does the product offer Passport authentication?
Passport SSI 1.4 Authentication - provides Passport Single-Sign-In authentication.
Security Infrastructure Device Locking
Does the product offer any means of locking the device or computer?
PIN, Password, Smart Card based Start UIs are available. This is almost always linked to hardware design.
Credentials Use
Does the product offer features that support the transparent use of users' passwords or other credentials by applications or the operating system?
Credential Manager component is available to cache NTLM, Kerberos creds. APIs are similar to the desktop but implementation is quite different
Credentials Management
Does the product offer features that enable users to manage their passwords or other credentials?
see "Credentials Use" above
Key Use
Does the product offer features that support the transparent use of users' cryptographic keys by applications or the operating system?
via CryptoAPI 1.0 and 2.0
Key Management
Does the product offer features that enable users to manage their cryptographic keys?
Keys are stored in the registry and encrypted using CryptoAPI 1.0 functions. No strong key protection.
Page 24
Appendices
Topic
Certificate Use
Meaning
Does the product offer features that support the transparent use of users' digital certificates by applications or the operating system?

via CryptoAPI 1.0 and 2.0
Certificate Revocation
Does the product offer features that support revocation of digital certificates?
Certificate Revocation Lists (CRLs) omitted from CryptoAPI 2.0. Plan to implement CertVerifyRevocation() API to allow others to plug-in their own revocation engine.
Certificate Server Support
Does the product offer features that support Microsoft Certificate Services?
MS Windows 2000 Certificate Services. Sample cert enrollment tool that leverages MSCA web front end. No XENROLL.
Certificate Repository Support
Does the product offer a repository for digital certificates?
Certificate storage CAPI 2.0 (*Note that only a subset of CAPI from Win2K is implemented in CE). "My" and "Root" System stores are supported. No AD stores or group policy stores. No CTL . No PFX.
Certificate Management
Does the product offer features that enable users to manage their digital certificates?
via CryptoAPI 1.0 and 2.0, though only a subset of CryptoAPI 2.0 is implemented. No auto root cert update.
Rights Management IRM Support
Does the product offer Information Rights Management features (including Digital Rights Management features)?
Microsoft Windows Media DRM v7.1, except client revocation
WMDRM
Does the product offer support to Windows Media DRM?
Support Windows Media 7.1 DRM and PD-DRM (Portable Device DRM)
Security Hardware Hardware-based Security Platform Support
Does the product offer support to platforms that offer hardware-based security (e.g., Next Generation Secure Computing Base, TCPA)?
Custom hardware can provide TCPA-like features which can be leveraged via CryptoAPIi
Page 25
Appendices
Topic
Biometric Support
Meaning
Does the product offer biometric authentication?

Many 3ed parties suppliers support Biometric devices. XXX provides signature recognition as a form of Biometric
Smart Card Support
Does the product offer support for smart cards?
Serial, Parallel, USB Smart Card readers supported. A sample Smart Card CSP is also provided.
Authentication Token Support
Does the product offer support for authentication tokens?
EAP supports 3rd party EAP providers
Software Access Control Software Restriction Support
Does the product offer features that allow an administrator to restrict, on a program-byprogram basis, which applications users can run?
Allows modules to be designated as "trusted" or "untrusted" when signing applications. This is done by the OEM but not an administrator. The OEM can choose to either run the app as Trusted, Untrusted or not load it at all depending on the signature. A custom bootloader linked ot device image au8tnetication can be implemented to link application permission to particular imate and instance..
Managed Code Support
Does the product offer any features that support the use of managed code?
The CF and C# Provide a managed code environment which does a good gob of controlling 'buffer overruns' that can plague secure applications. There are also 3ed parties like Insignia Solutions that can offer Java for CE.NET
Bootloader Security
Does the product offer features for securely updating flash ROM?
Boot loaders are typically custom and specific to the device. Boot loaders can incorporate security code to authenticate the software as it loads.
Installation Security
Does the product offer a security check as applications are installed onto the device?
The OS and applications can be loaded in many ways- the typical scenario for a secure system is to load in a secure facility, as part of the Functional Test process . OS and application will be identified to the device as they load.
Execution Security
Does the product offer a security check as applications are executed on the device?
Support a 2-tier Security Model (aka Trusted Model). Trusted processes have complete access to the system, while untrusted processes have limited access. See details at: http://msdn.microsoft.com/library/enus/wcedsn40/html/cmconCreateTrustedEnvironment.asp
Miscellaneous Cookie Support
Does the product offer features that create, store or use cookies?
WinInet Cookie functions: InternetGetCookie, InternetSetCookie/Ex
Antivirus Support
Does the product offer anti-virus features?
Hooks available in the OS to allow filters to sit on top of the File System so 3rd parties can write anti-virus filters. Mulitipe companies offer these filters.
Page 26
Appendices
Topic Meaning Supplementary Data, Comment
IDS Support
Does the product offer intrusion detection features?
known-secure protocols such as used by Forftress are recgnized by popular IDS monitors
Page 27
Appendices
Appendix 2-Various Standards Associated with Security
ISO/IEC ISO/IEC DTR 13335 ISO/IEC 17799 ISO/IEC 15408 ISO/IEC 10181 ISO/IEC 13569 ISO/IEC 9735 ISO 9564-2:1991 ISO 11568 Banking Key Management (Retail) ISO 15782 Banking Certificate Management ISO/IEC 9579:2000 CCITT / ITU X.802 X.803 X.810 X.811 X.812 X.813 X.814 X.815 X.816 NIST FIPS Pub 102 FIPS Pub 191 NBS Spec Pub 500-133 NIST Spec Pub 500-169 NIST Spec Pub 500-170 NIST Spec Pub 500-171 NIST Spec Pub 800-12 NIST Spec Pub 800-14 NIST Spec Pub 800-18 NIST Special Publication 800-30 US Department of Defense DoD 5200.28-STD DoD 5220.22-m Internet Engineering Task Force RFC 2196 RFC 2504
Page 28
Appendices
Appendix 3- Table of Contents For An Actual Protection Profile
TheTarget of Evaluation is Virus Protection Software, to be approved according to Common Criteria. I have put in bold text the key points mentioned in this paper:
1. Introduction 1.1 Identification 1.2 Overview 1.3 Mutual Recognition of Common Criteria Certificates 1.4 Conventions 1.5 Glossary of Terms 1.6. Document Organization 2. Target of Evaluation (TOE) Description 2.1 Product Type 2.2 General TOE Functionality 2.3 Cryptographic Requirements 2.4 TOE Operational Environment 3. TOE Security Environment
3.1 Threats
3.2 Security Objectives and Policy
3.3 Security Usage Assumptions

4. Security Objectives 4.1 TOE Security Objectives 4.2 Environment Security Objectives
5. Security Functional requirements

5.1 Security Audit (FAU) 5.2 Cryptographic support (FCS) 5.3 User Data Protection (FDP) 5.4 Identification and Authentication (FIA) 5.5 Security Management (FMT) 5.6 Protection of the TOE Security functions (FTP 5.7 Resource Utilization (FRU) 5.8 TOE Access (FTA) 5.9 Trusted Path/Channels (FTP) 6. Security Assurance Requirements 6.1 Configuration Management (ACM) 6.2 Delivery and Operation (ADO) 6.3 Development Documentation (ADV) 6.4 Guidance Documents (AGD) 6.5 Life cycle support (ALC) 6.6 Testing (ATE) 6.7 Vulnerability Assessment (AVA) 7. Rationale
(Measures From Here Down)
(How and why Threats, Objectives and Countermeasures were aligned this way)
7.1 7.2 7.3 7.4 7.5 Security Objectives derived from Threats Objectives derived from Security Policies Objectives derived from Assumptions Requirements Rationale Explicit Requirements Rationale 7.5.1 Explicit Functional Requirements 7.5.2 Explicit Assurance Requirements 7.6 Rationale for Strength of Function 7.7 Rationale for Assurance Rating
Page 29
Appendices
Appendix 4- CERT Listing
Recent Vulnerability Notes (Date Jan 5 2004, From CERT Site) VU#288308 Microsoft Internet Information Server (IIS) vulnerable to cross-site scripting via HTTP TRACK method VU#734644 ISC BIND 8 vulnerable to cache poisoning via negative responses VU#940388 GnuPG creates ElGamal keys for signing using insufficient entropy VU#652278 Microsoft Internet Explorer does not properly display URLs VU#148564 Apple QuickTime/Darwin Streaming Server integer overflow in MP3Broadcaster utility VU#352462 Cisco ACNS contains buffer overflow vulnerability in the authentication module when supplied an overly long password VU#909678 DameWare Mini Remote Control vulnerable to buffer overflow via specially crafted packets VU#707100 Multiple web-based email services fail to filter malicious characters when the message contains cascading style sheet character escaping VU#325603 Integer overflow vulnerability in rsync VU#301156 Linux kernel do_brk() function contains integer overflow Tabulation By Supplier Microsoft: 3ed Party Windows: Various Unix/Posix/Linux: 2 1 6
Page 30
Appendices
Appendix 5- Third Party Windows CE Security Software
All statements made below are based on the vendors claims for the product and have not necessarily been checked. Also- remember PPC is not CE.NET and programs designed for one may not run on the other without some adaptation.
Airscanner Mobile AntiVirus Pro. Offers Automatic, easy, online updates of virus signatures and scanning engine. It is fast, with optimized scanning speed based on patent pending technology. Support for PocketPC 2003/Windows Mobile 2003. avast! 4 PDA Edition is designed to protect pocket devices (PDA) from viruses. The program includes: High speed, Scanning kernel; Reports & logs; Updates. avast! PDA Edition detects only the viruses (or any other malicious code) written for the target environment (i.e. the code capable of running in given OS). BitDefender AntiVirus for Windows CE is an anti-virus software specially designed for devices using the Microsoft Windows CE operating system, it is built on the cutting edge "plug-in" technology, allowing fast customization and upgrades. Bluefire Security Technologies provide Compact Firewall and Intrusion Detection System (IDS) for protection against viruses and attacks on mobile devices and provides a centralized console for policy-based management across large-scale mobile device deployments. Bluefire Mobile Firewall Plus provides Firewall, intrusion prevention, integrity management, authentication, encryption and enterprise security management features that enable the safe use of mobile and wireless applications. Computer Associates eTrust anti-virus protection for mobile devices. eTrust Antivirus provides enterpriseclass protection against virtually all forms of costly virus and malware attacks from the PDA to the gateway . Dual virus-scanning engines provide double the protection, superior management, FREE signature updates, and the eTrust TARGET offer cost-effective protection for todays networks against potentially damaging and costly virus incidents. InoculateIT is an anti-virus solution for networked environments sold via Symbol Technologies including Windows CE devices offering management and virus protection. Features of InoculateIT include Real-Time Cure, Universal Manager, Virus Wall, Virus Quarantine, Hands-Free Updates, Extensive Alerting Options, Internet Web Browser Integration, and Messaging Protection. Fortress Technologies AirFortress, is an embedded communication stack that allows very secure wireless communication, even over commercial 802.11 cards and access points. The software has been tested according to Common Criteria F-Secure Anti Virus Software This anti-virus for mobile devices provides on-device background virus checking with automatic virus database updates in corporate environments or over wireless connections. The F-Secure management software also handles distributions of crypto-keys and password management. Handango Vault is a secure, encrypted database for storing sensitive data on your handheld device. Handango Vault uses BlowFish encryption to keep your data safe. The database has predefined fields for login names, passwords, URLs, and more. You select which fields to display for each entry. Data can be exported to MemoPad for printing from your desktop. Plus, there is only one password to remember. Handango Security Guard helps businesses or individuals get control by securing data and controlling application access with password protection. It also includes Trend Micro PC-cillin virus protection software that can scan applications at regular or user-determined intervals to ensure that the handheld remains virus free. It even has a smart-lock feature that lets you determine when to allow a grace period for password entry. It provides file and data encryption along with virus protection. IIris CAT (for Windows CE) is a anti-virus product for the compact operating system. The software protects Win CE device users from viruses lurking inside of transferred files on the new small systems. Kaspersky Security for PDA This software provides protection of personal data stored on mobile devices running the Windows CE operating system. The system offers Anti-Virus features, and encryption of locally stored data. Odyssey Software AppCenter was developed to give an administrator control over how a portable or mobile devices are set up, with defined permissions to user and administrator. AppCenter runs on
Page 31
Appendices
CE or PPC devices. It is currently resold as part of certain Symbol products Trend Micro PC-cillin for Wireless 2.0 offers automatic, real-time scanning to protect wireless devices and computers from potential threats that can occur when downloading files from the Internet, beaming, and during synchronization. It provides portable, easy-to-use antivirus security to defend wireless devices against malicious code and viruses hidden inside files, email, or on the Web. Trust Digital Trusted Mobility Suite This very complete suite of products offers strong protection in a centrally managed manner. Trust has achieved FIPS 140 Level 2 certification.
Page 32
Appendices
Copyright , Applied Data Systems, Inc, 2003-2004. All Rights Reserved. This document may not be used for commercial gain without permission of Applied Data Systems, Inc. Any trademarks used within are the property of their respective owners. This document contains technical descriptions that may not be representative of Applied Data Systems product or services
Page 33

White Paper - Embedded System Security

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

White Paper - Embedded System Security

Hochgeladen von

Copyright:

Verfügbare Formate

Embedded System Security

About the Authors

Devise Countermeasures(people, processes, measures and procedures)

The options selected will depend on the sensitivity of the data.

Current State of Security for Mobile Devices

Figure 1-Simple Embedded Device in Failure Mode From Protocol Attack

Dr. Markko Lasco of Oulu University, Secure Programming Group http://www.ee.oulu.fi/research/ouspg/index.html

Applying Common Criteria to Secure Embedded System Design.

Existing, Typical Protections Profiles

The Hostile Hands Assumption.

Figure 3 Comparison of Threats

Portable and Fixed Environment Portable Device Secured Workstation

Secure Embedded System Threat Assessment and Possible Countermeasure

The Descartes Problem I Think, Therefore I am- WHAT??

Security in a Small Room

Minimize the build.

Minimize the ports

Extra-Careful Code Review of Drivers and Applications

Safe Code Throughout

A common problem, yes

The compiler catches missing parameters long before execution

Software Considered Harmful: Why Software is Insecure Juha Roning http://www.ee.oulu.fi/research/ouspg/protos/sota/CorpSec2002/index.html

Traceability and Security of Code During Development

Omit Needless Data, Encrypt the Rest

Security Trail and Audit

Fast Zero Base

Security Inside the Shrink-wrap

Chris De Herrera's Windows CE Website (ttp://www.cewindows.net/reviews/pocketpc2002security.htm)

Supplementary Data, Comment

Does the product offer support for Wireless Application Protocol?

Does the product offer support for 802.1x authentication?

PPTP and L2TP/IPSec available for both client and server

Does the product offer EAP authentication?

Does the product offer PPP authentication protocols?

Does the product offer support for Point-to-Point Tunnelling Protocol?

Does the product offer support for Layer 2 Tunnelling Protocol?

Does the product offer support for Internet Protocol version 6?

The complete list of supported RFCs can be found in MSDN: http://msdn.microsoft.com/library/enus/wcemain4/html/cmpssipv6rfcsinternetdrafts.asp

Does the product offer support for IP Security Protocol?

Supplementary Data, Comment

Patch/SP Deployment Support

Patch/SP Scanning/detection Support

Application Deployment Support

Can the product be remotely installed?

This feature is offered by a 3ed party, Rapport Technologies

Remote Deactivation/Device Kill

Supplementary Data, Comment

Full ROM update

Digital Signature Support

DSA, RSA. CryptoAPI 1.0 for signing.

SHA-1, SHA-2, MAC, HMAC, MD2/4/5.

Cryptographic API Support

Does the product offer any cryptographic API sets?

Does the product offer NTLM authentication?

Does the product offer Kerberos authentication?

Does the product offer SPNego authentication?

Support similar to WinXP

Supplementary Data, Comment

SSL 1.0/2.0/3.0, TLS 1.0.

Does the product offer Passport authentication?

Passport SSI 1.4 Authentication - provides Passport Single-Sign-In authentication.