The last decade has seen a significant increase in the numbers and types of wireless systems. While these technologies allow for the easy connection of mobile platforms to peripherals, local networks and the internet, the connections are over the air and can be intercepted and altered, making them a potential source of security breaches.
Wireless security is therefore a major concern. While network security is a 'standard' infrastructure issue, what about the security of the firmware within the wireless devices?
There has been talk about the emergence of a new breed of programming guidelines from the US funded organisation CERT. Languages such as C, C++ and Java are being tackled, with the goal of producing of safe, secure and reliable systems.
CERT (www.cert.org) was created by DARPA in 1988 to deal with internet security problems after the Morris Worm struck. Its coordination centre (CERT/CC) is located at Carnegie Mellon University's Software Engineering Institute (SEI).
Although intended as an academic exercise to gauge the size of the internet, the Morris Worm had widespread repercussions and infected thousands of machines.
SEI CERT/CC was established to deal with internet security and, for 12 to 15 years, 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 that eliminate insecure coding practices and undefined behaviours that can lead to exploitable software vulnerabilities. Developing code in compliance with CERT C leads to higher quality systems that are robust and more resistant to attack.
Internet connectivity is a primary source of malicious attacks on software systems. These attacks are now focusing on the components integral to wireless connections. With more and wider connectivity, there is a need 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 that lead to software defects, security flaws and software vulnerabilities. The standard also 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.
What is software vulnerability? CERT/CC describes a 'vulnerability' as a software defect which, when present in information systems, affects security. The defect may be minor, in that it does not affect the software's performance or results, but which nevertheless may be exploited and result in a significant breach of security. CERT/CC estimates that up to 90% of reported security incidents result from the exploitation of defects in software code or design.
The Secure Coding Initiative aims to work with developers to reduce the number of vulnerabilities introduced into secure software by improving coding practices through the provision of guidelines and training.
Wireless security issues
Two classes of wireless interface will be considered. Firstly, there are embedded interfaces contained within a 'box' that provides some functionality and which cannot easily be replaced, upgraded or modified by the user. Secondly, there are peripheral interfaces which can easily be replaced, upgrade or modified by the user.
Both classes of device contain firmware that is responsible for ensuring that authorised systems can connect to each other and for routing information between such connected systems. This software generally runs within the OS kernel and has privileged access to the system that hosts it. This means it has the potential to access all data and/or hardware, regardless of whether or not it is related to wireless communications. From this, it is obvious that 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 and so on. In fact, an internet search will show that organisations such as CERT 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 of the identified vulnerabilities are eliminated from future code releases, it is common for many deployed systems to not benefit from this work via updates. While pc drivers may be updated as part of the rollout of routine security updates, embedded devices are often 'ignored' as the updates can be more difficult to apply and some devices are simply 'forgotten'.
How does CERT C help?
CERT C guidelines define rules that must be followed to ensure that code does not contain defects which may be indicative of errors and which may, in turn, give rise to exploitable vulnerabilities. For example, guideline EXP33-C says: 'Do not reference uninitialised memory'. This gives protection against a common programming error often associated with the maintenance of complex code.
Consider this example:
int SignOf ( int value )
The SignOf() function has a UR dataflow anomaly associated with sign. This means that, under certain conditions (for instance, if value has a value of '0'), sign is Undefined before it is Referenced in the return statement. This may lead to an error. For example:
int MyABS ( int value )
{
return ( value * SignOf ( value ) );
}
MyABS() will work as expected during testing, even though the return value of SignOf() will contain whatever value was in the storage location allocated to sign when called. 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 )
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; there is little chance of it causing an error during testing, even if that testing is robust.
Reducing vulnerability
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.
Adoption of the CERT C guidelines will reduce the number of vulnerabilities within wireless interfaces. However, these benefits will only be realised if tools are available that check code automatically for compliance with the standard.
Author profile:
Chris Tapp is a field applications engineer with LDRA.
