Security for Wireless Networks
Wireless Security and CERT C
A set of programming standards is designed to prevent the kinds of errors that can result in security breaches. When combined with automatic tools that can test code for compliance, firmware in wireless networked devices can be made more secure.
CHRIS TAPP AND PAUL HUMPHREYS, LDRA
Page 1 of 1
The widespread adoption of wireless technology in embedded systems, such as wireless DSL routers, printers, streaming audio devices, PDAs and smart phones, over the past decade has led to a significant increase in the numbers and types of wireless systems that are in use. These include Bluetooth, Wi-Fi, ZigBee, Wireless USB, 3G and other telecoms.
These technologies allow for the easy connection of mobile platforms to peripherals, local networks and the Internet. However, since these connections are over-the-air, they can be intercepted and altered by third parties making them a potential source of security breaches.
Wireless security is therefore a major concern, and there are two main aspects that need to be considered when implementing wireless systems. First, the network needs to be secure. Since network security is a “standard” infrastructure issue, it will not be considered further here. However, let’s focus on the second concern—the security of the firmware within the wireless devices. The security of such firmware can be enhanced by applying the guidelines contained within the “CERT C Secure Coding Standard.”
During 2008 there was a great deal of positive talk about the emergence of a new breed of programming guidelines from the U.S. federally funded organization, CERT. Languages such as C, C++ and Java are being tackled, with the goal of producing safe, secure and reliable systems. Currently, though, it is CERT C that has made a splash. In October 2008, version 1.0 of the standard made its debut at the Software Development Best Practices exhibition in Boston. Both C++ and Java secure coding standards are works in progress at present, so for this discussion we focus entirely on the CERT C Secure Coding Standard.
What Is CERT C?
CERT was created by Defense Advanced Resource Projects Agency (DARPA) in November 1988 to deal with Internet security problems after the Morris Worm struck. Its coordination center (CERT/CC) is located at Carnegie Mellon University’s Software Engineering Institute (SEI).
Although intended purely as an academic exercise to gauge the size of the Internet, the effect of the Morris Worm had repercussions throughout the worldwide Internet community and infected thousands of machines. Many organizations with systems attached to the Internet suffered damaging denial of service attacks.
Consequently, software vulnerabilities came under the microscope of various bodies, including the U.S. government. The SEI CERT/CC was primarily established to deal with Internet security problems in response to the poor perception of its security and reliability attributes. Over a period of 12-15 years, the CERT/CC studied cases of software vulnerabilities and compiled a database of them. The Secure Coding Initiative, launched in 2005, used this database to help develop secure coding practices in C.
The CERT C Secure Coding Standard provides guidelines for secure coding in the C programming language. Following these guidelines eliminates insecure coding practices and undefined behaviors that can lead to exploitable software vulnerabilities. Developing code in compliance with the CERT C Secure Coding Standard leads to higher quality systems that are robust and more resistant to attack.
Internet connectivity is clearly a primary source of malicious attacks on software systems. These attacks are now focusing on the components integral to wireless connections. A dependency on connected software systems is not just relevant to corporations or individuals, but also to government and civil infrastructure such as industrial plants, power generation and transmission. More and wider connectivity is becoming integral to the way people work and live. There is a need, therefore, for systems to be impenetrable whether from IT-based hackers or from devices and equipment under the control of those with malicious intent. On this basis, CERT C considers the overall and far-reaching need for secure coding practices.
The primary aim of CERT C is to enumerate the common errors in C language programming that lead to software defects, security flaws and software vulnerabilities. The standard then provides recommendations about how to produce secure code. Although the CERT guidelines share traits with other coding standards, such as identifying non-portable coding practices, the primary objective is to eliminate vulnerabilities.
And so, what is software vulnerability? The CERT/CC describes a “vulnerability” as a software defect that affects security when it is present in information systems. The defect may be minor, in that it does not affect the performance or results produced by the software, but nevertheless may be exploited by an attack from an intruder that results in a significant breach of security. CERT/CC estimates that up to ninety percent of reported security incidents result from the exploitation of defects in software code or design.
What Security Issues Are There with Wireless?
There are two classes of wireless interface that will be considered. First, there are embedded interfaces contained within a ‘box” that provide some functionality (e.g. a wireless access point or DSL modem/router) and which cannot easily be replaced, upgraded or modified by the user. Second, there are peripheral interfaces like PCI cards and USB devices that can easily be replaced, upgraded or modified by the user.
Both device classes contain firmware that is responsible for ensuring that authorized systems are allowed to connect to each other and for routing information between such connected systems. This software generally runs within the kernel of an operating system and has privileged access (akin to “superuser” or “admin” rights) to the system that hosts it, meaning that it has the potential to access all data and/or hardware regardless of whether or not that data and hardware are related to wireless communications. From this, it is obvious that any vulnerabilities in the firmware may lead to the exposure of sensitive data or allow the execution of arbitrary code at an escalated privilege level.
It is possible for an external agent to exploit vulnerabilities within a wireless system. This could allow eavesdropping of sensitive data, denial of service attacks, redirection of communications to locations containing malware and/or viruses, man-in-the-middle attacks, etc. In fact, a quick Internet search will show that organizations such as CERT, SANS, etc. have many reports of wireless system vulnerabilities that could have permitted such attacks. These include integer overflows leading to arbitrary code execution and denial of service, and specially crafted network packets allowing remote code execution with kernel privileges and local information disclosure.
While many, if not all, of the identified vulnerabilities may be eliminated from future code releases, it is common that many of the deployed systems do not benefit from this work via updates. PC drivers are generally updated as part of the rollout of routine security updates, at least within the corporate environment. However, embedded devices are often ignored as the updates are often more difficult to apply, and some devices are simply forgotten about.
How Does CERT C Help?
The CERT C guidelines define rules that must be followed to ensure that code does not contain defects that may be indicative of errors and that may in turn give rise to exploitable vulnerabilities. For example, guideline EXP33-C says “Do not reference uninitialized memory,” giving protection against a common programming error often associated with the maintenance of complex code. Consider the following example:
int SignOf ( int value )
if ( value > 0 )
sign = 1;
else if ( value < 0 )
sign = -1;
The SignOf() function has a UR dataflow anomaly associated with sign. This means that, under certain conditions (i.e. if value has a value of ‘0’), sign is Undefined before it is Referenced in the return statement. This defect may or may not lead to an error. For example:
int MyABS ( int value )
return ( value * SignOf ( value ) );
MyABS() will work exactly as expected during testing, even though the return value of SignOf() will contain whatever value was in the storage location allocated to sign when it is called (zero multiplied by any integer value is zero). The code is said to be “coincidentally correct” as it works, even though it contains a defect. However, all uses may not be so fortunate:
void Action ( int value )
if ( -1 == SignOf ( value ) )
NegativeAction ( );
PostiveAction ( );
The code in Action() is most likely to call PositiveAction() when it is called with a value of ‘0’ (which is likely to be correct), as only a return value of (exactly) ‘-1’ will cause it to do otherwise. It is likely that a latent defect will be present in released code as there is little chance of it causing an error during testing, even if that testing is robust.
While compliance with the CERT C guidelines can, in theory, be demonstrated by manual checking, this is not practical for large or complex systems. To that end, tools are available to automate the compliance checking process. Figure 1 shows an example of how the LDRA tool suite reports the dataflow anomaly in the SignOf() function.
Automated tool checking for compliance is a cost-effective and efficient method to demonstrate compliance with the requirements of CERT C. Such a demonstration provides evidence to support any claims that are made with respect to the inherent security of a wireless product.
Adoption of the guidelines contained within CERT C will significantly reduce the number of vulnerabilities within wireless interfaces. However, these benefits will only be realized if tools that automatically check code for compliance with the standard are available to the developers.
CERT launched the Vulnerability Discovery Project, which promotes the use of test tools and techniques, to help ensure that suitable tools are available. The aim is to develop a process that may be used systematically by developers and testers to discover and eliminate all vulnerabilities in software.
+ 44 0151 649 9300.