Security inadequate in RTOSes

With growing evidence that cyberterrorists may be planning attacks on computer-controlled civilian targets, the distinction between military/ government systems and private/commercial systems has become meaningless where security is concerned. It's clear that commercial entities must make their systems just as secure against internal attacks as military and government entities do, and the primary defense is the mechanisms residing in real-time operating systems.

Fortunately, security standards for military and government applications have included protection against internal attacks for a long time, with methodologies that have been perfected over the years for embedded systems such as those used in the F-35 Joint Strike Fighter and the S-92 Sikorsky helicopter. These standards are available to anyone who wants to use them. They include DO-178B, common criteria evaluation-assurance levels (EAL) 1-7, ARINC-653 and Multiple Independent Levels of Security (MILS).

DO-178B provides guidelines for the production of airborne-systems equipment software that is safe and airworthy. It describes techniques and methods to ensure the reliability of such software and is used to secure FAA approval of digital computer software. The Common Criteria for Information Technology Security Evaluation defines seven EALs for system security, with Level 7 being the highest, providing maximum security. A key provision of EAL is section 6.2.4, which says that EAL-4 is the highest level to which it is likely to be economically feasible to retrofit an existing target operating environment.

Program boundaries|

What this means to the developer is that to achieve a security rating higher than Level 4, protection must be designed in from the ground up. The F-35 Joint Strike Fighter, for example, requires EAL-7, which is the most demanding. This requirement serves to ensure that every possible mechanism for violating security will be anticipated and planned for in every particular of the OS, so that no program can adversely affect any other program in the system.

The ARINC-653 standard defines an application/executive software interface between the OS of an avionics computer and the application software, in a manner that enables the application software to control the scheduling, communication and status of internal processing elements. The most important criterion is the requirement that no program may adversely affect another program in the same system.

The MILS standard requires a partitioned RTOS that can be proved, through rigorous testing, to be secure. Both memory protection and guaranteed resource availability are required to implement MILS on a single processor and this is the current preference for military/defense systems.

These standards set up the criteria that a developer must meet in order to have an application certified but they do not tell you how to go about designing your application to meet the standard. That is entirely up to the developer.

All system threats, whether a bug, a virus or a hacker, can result in one of two malfunctions within the system: unauthorized access to a protected portion of memory, or denial-of-service affecting either the CPU or memory.

The very fact that a virus or a hacker has invaded a system means that damage has already been done, since their presence is usually discovered only because a malfunction has been detected. Thus, protection from internal attacks is based on the principle of "containment," meaning that destructive activity is confined to a single compartment or segment of the system and not allowed to cross over into other compartments, thus limiting the amount of damage it can do. Most of the mil/gov security standards are based on this principle. Containment is accomplished through two main strategies: memory protection and guaranteed resource availability.

Memory protection is the process through which the data and instructions of one program are protected from being changed by the unauthorized actions of another program. Memory management, usually implemented through a hardware memory management unit (MMU), is a key element in memory protection. Through the process of partitioning, it ensures that portions of memory are reserved for the use of particular programs, and that no other program uses those segments of memory.

However, memory that is not reserved for the use of a particular application becomes part of the system memory pool. The OS, not the MMU, uses this pool to respond to requests from individual tasks to send messages to other parts of the system or to accumulate additional input data, and of course each message requires a certain amount of memory. If a rogue program-created by a virus, a hacker or a bug-manages to establish itself in any one of the segments created by the MMU, it can render the entire system useless by draining available memory from the system pool, even if the virus itself is restricted to the one compartment it has managed to invade. Memory protection offers no defense against this.

Memory protection does not defend the system against denial-of-service attacks, one of the more common virus strategies. The denial-of-service that everyone is familiar with is the attack from outside, such as the ones that occurred in February 2000 when Yahoo, CNN and eBay were brought down by denial-of-service attacks that reputedly caused more than $1 billion in losses.

But there is a form of denial-of-service that is more insidious. It is an internal attack that occurs when an activity in one portion of a system drains the resources of the system, either by consuming all of the CPU's processing power by sending a never-ending series of requests for service to the CPU, or by sending endless messages that must be allocated memory from the system memory pool. To protect against denial-of-service, guaranteed availability of resources is needed in the time domain, which refers to CPU cycles, and the space domain, which refers to memory.

Guaranteed resource availability prevents both of these kinds of attacks by putting limits on how much of the memory and how much of the CPU's resources any particular task can ask the system to use on its behalf.

We use an approach called "hard currency." In the space domain, hard currency means that a certain "budget" of memory is allocated to each address space and a portion of that memory, rather than memory from the system pool, must be made available to the RTOS when services are requested. If a bug or virus begins to proliferate in a particular address space, the address space's memory budget will be exhausted, and no further RTOS services can be requested.

In the time domain, when a program requests that the RTOS send a message, open a file or schedule a task, the kernel uses CPU time from the requesting program's budget. It is not allowed to use time that has been budgeted for other tasks. If a virus or a bug causes unlimited requests, the requesting task will therefore run out of its budgeted CPU time and the requests will stop. CPU time budgeted for other tasks will remain untouched.

See related chart