Network RTOSes vulnerable to attack

Much of the discussion regarding Internet security has focused on enterprise-level answers to problems arising from authentication of system access. But network-connected embedded systems do more than exchange information with other participants. Their interactions are often to download commands, even new programs, for the embedded system to execute automatically. Once the program is in the system being executed, it has virtually unlimited access to all system resources. Commercial real-time operating systems (RTOSes), used in most embedded system designs, have no way to prevent those programs from drastically affecting system operation.

As a first line of defense, the authentication and encryption schemes used to validate the interaction will help protect against a malicious program's even entering the system. No defense is perfect, however. There are plenty of ways for senders of information to hide themselves and appear to be something else. Once an embedded system downloads a program that appears to be authentic, there is no way to stop whatever it is going to do.

This vulnerability is the result of a feature common to every commercial RTOS: They all allow application software processes full access to system resources.

In a controlled programming environment, that doesn't present a problem. Applications developers need full access to system resources and use that access responsibly. If one software process accidentally does something to interfere with another, developers correct the situation before the software is released.

For nonconnected embedded systems, that methodology works well. Once released, the software remains unchanged, so there is no need for internal protection.

With a network-connected embedded system, though, the situation changes. The new programming that comes over the network still has full access to system resources. Any process that the program initiates may query memory, send messages to other processes, make system calls and access I/O resources without restriction. Memory management and other protections that some RTOSes offer will guard against accidental interference among programs, but they do not offer protection against deliberate attempts to crash the system.

Crashing a net-centric iAppliance or embedded system is easy. Setting I/O ports to a random configuration, shutting down interrupts, scrambling configuration parameters and altering process priorities are simple operations that can have catastrophic consequences in a small-footprint device and on the system in which it resides. In a set-top box, they might simply disable the device. In a petrochemical plant, they could cause considerable damage.

Such malicious programs can enter an embedded system in many ways. Set-top boxes, for example, accept new programming over a network connection. Fooling whatever security the system possesses to identify trusted programming sources gives an attacker full access to the box's resources.

Industrial process controllers can't be reprogrammed over the Internet but do respond to configuration commands from other software on the company's network. In such cases, compromising security anywhere along the command chain gives an attacker access to the process.

Once false commands have been entered at the chain's weakest link, all subsequent stages will dutifully follow them. In such cases even validation and encryption offer no protection, because the falsified message is coming from a legitimate source.

To bolster embedded systems, their real-time operating systems need enhancement. The RTOS is the logical place to add the security because it controls an embedded system's operation on a fundamental level. All applications software must interact with the RTOS to access system resources, so it is in an ideal position to prevent malicious behavior.

Needed modifications
Because system security on small-footprint-connected iAppliances and embedded systems is only now being examined, there is no definitive list of RTOS modifications to recommend. Several will be needed, however, because the various threats that exist require different responses:

• Threat 1 is the malicious program uses message queue handles to send false messages.
• Threat 2 i an RTOS that allows applications programs to call on system kernel operations so that an attacker simply masks system interrupts, as it might if it were performing a time-critical task. Without interrupts, real-time systems quickly fail.
• Threat 3 is allocation of memory for a task-a normal behavior that can become a hazard. It's easy to bring down a system by exhausting its memory resources through overallocation.
• Threat 4 is that memory protection schemes do not prevent a program from reading that data from another program. A malicious program could simply read the entire system memory and download the data over the network to a waiting listener.

These examples only touch the surface of what is possible for malicious programs, but they illustrate the need for change.

For more on dealing with threats, see the complete article online at www.eet.com/in_focus/.