News :: story cache

Game theory in the popular press.

Does Obscurity Equal Security

Software Development Times
Edward J. Correia
December 15, 2001
text is a cache of

Closed-source embedded RTOS vendors claim fewer eyes are better for protecting network devices

How secure is your embedded device against software threats? As seemingly indefatigable antagonists create a constant threat of network system failures, developers have begun to realize that they may be reaching the limits of application and network security, and are looking to the operating system itself to take on more of the protective responsibilities, thereby serving as the last line of defense once network safeguards have been circumvented.

But according to Bob Monkman, director of product marketing for core technologies and tools at embedded systems developer OSE Systems, many times the operating system isn’t up to the task. “Security as a whole has not really made its way beyond preventing access to the box. The network is the way in, so security has to be there. But with the vast majority of operating systems, once you have access to the machine, you can go in and read/write memory, and really destroy the machine.”

Expanding on the point was Bill Weinberg, director of strategic marketing at embedded Linux developer MontaVista Software Inc. ( “A malicious piece of code could corrupt other applications or the kernel, bring down the system or change its functionality” and could control the system’s I/O devices.

Weinberg said that systems most at risk are those not built with security in mind from the outset. “An area that is especially vulnerable is where you take old-style systems and tack on networking after the fact. They are unstable because the networking is not native to them,” and therefore network security is like a “Band-Aid on top of a Band-Aid.”

Eric Hemmendinger, research director at Aberdeen Group, supported Weinberg’s contention. “Outside the RTOS world, security usually involves injecting mechanisms that make decisions about certain behaviors before they reach the operating system, and the computer moves slow enough to allow that. With an RTOS, you don’t have that option unless you build it into the operating system. Because of this need to hook in at the foundation level, it’s useless to view security in the RTOS context as something you can bolt on afterward.”

Monkman said that more often, developers are asking for protections such as encrypted memory, service denial or limiting access to memory based on user profile. “The RTOS is a perfect place for addressing security because it controls access to memory and services,” he said.

According to Monkman, high availability and security are spokes on the same wheel. “One is more concerned with reliable execution and machine resources that continue to operate. The other is more focused on preventing malicious use of resources or denial of services. This is just emerging and still focused on connectivity, but more people are looking for the RTOS to provide more of an overall security model,” he said.

Hemmendinger added that when approaching the problem of denial-of-service attacks, developers are focused less on identifying the problem “at the first possible device” and more on “preventing it from moving further upstream or downstream.”

John Gordon, senior member of technical staff at Wind River Systems Inc., asserted that the most vulnerable of today’s embedded operating systems are those that originated as desktop systems. “Linux and the embedded forms of Windows are the weakest simply because most of the attacks today are targeting the desktop variations of these operating systems, and any weaknesses found there will probably be found in the embedded forms, too.” Wind River develops and markets VxWorks, a proprietary operating system.

Gordon said that two central elements of security are secrecy and simplicity. “The relative obscurity of both proprietary and homegrown systems makes them harder to attack, though not impossible,” he said. “Embedded systems tend to be using unknown architectures and tend to have simple menu-driven interfaces rather than shells,” he noted, adding that some deployed VxWorks systems in their purest form offer no services at all, but that “once network services [such as] a telnet daemon, Web server or SNMP agent are added, security issues are exposed.”

OSE’s Monkman held a similar view. “Now more than ever, people are becoming cognizant of who is trying to get to [their] machines and do things,” he said. Monkman explained that such activities have been more evident in the enterprise than in deeply embedded devices “because people are convinced that you really can’t get to these highly specialized devices” and wouldn’t know what to do anyway. “It’s not like a PC with known hardware and software. You can’t go in and write a program to run on an oil drill [for example].”

But MontaVista’s Weinberg warned that any supposition of obscurity can be dangerous. “In the proprietary software community, there’s a tendency to rely on secrecy and not on security. That is your ‘;what the public doesn’t know they can’t hack into’ [mentality]. It’s a common misconception that closed source and secrecy breed security. I will grant that [proprietary] RTOS codebases are so obscure that hackers are relatively inexperienced with them. But you can only stay invisible for so long. If you live in obscurity, you get a false sense of security.”

MontaVista develops and markets open-source software for embedded systems, including its Linux-based operating system. “Once you stop taking obscurity for granted, you become security-minded,” asserted Weinberg. He pointed to the innumerable open-source developers who take pride in their ability to fix security holes quickly. “It’s prestigious to repair exploits. If you look at it as game theory, any hawk that is going to exploit the open-source doves is going to be met by another hawk who is really an open-source dove whose vested interest isn’t in exploiting but in gaining prestige by repairing the exploit. There are more people on that side of the fence than on the exploiter side.”

Conversely, Weinberg alleges that proprietary operating-system developers prefer to keep their problems private. “The closed-source community has a vested interest in hiding all knowledge of both implementation and history of exploits to the point where their base position is denial.” He cites a well-known case in which Linux developer Alan Cox found a security bug in Solaris, which over the course of a year he tried to bring to Sun’s attention. “He got fed up and went out to the community and started screaming about it, and it still wasn’t fixed.” Weinberg claimed that in such situations involving the open-source community, “a patch would be available in hours and people would be using it within a day.”

Weinberg also claimed that the closed-source development process suffers from inadequate peer review. “Code review in this environment is usually compared with proctology, because neither side of the table enjoys the process. The communities that are developing proprietary software are too small to guarantee that they really are secure because there are not enough eyes looking at them. Open-source RTOSes benefit from broad exposure, quick exposure and repair of exploits, and a fondness and respect for standard practices so that when security is there, it is used correctly.” And while he admitted that the process does not guarantee that such exploits will be fixed, “the need to protect commercial interests through secrecy is practically a guarantee that exploits will occur and won’t be fixed.”

Paul Zorfass, senior analyst with research firm International Data Corp., said that the practice of concealing the negative aspects of products is commonplace, even among the open-source community. “They are both guilty of it, so what? The open-source people don’t identify every blemish that their operating systems have, and will clearly identify work-arounds and other creative solutions or ways of solving problems [when] the operating system is unstable in certain conditions. They have a greater crusade mentality and would like to dethrone those with larger market share.”

Despite their differences, most agree that system security has more to do with the way the RTOS handles memory and objects than whether its origins were from open- or closed-source code.

“Once you do get past the secrecy and networking security measures, the flat memory utilization becomes a huge disadvantage because there’s nothing to keep [hackers] from going further,” said MontaVista’s Weinberg, referring to the flat memory model used in most of today’s embedded systems. One exception is Linux, which employs virtual memory and addressing to protect application code.

According to Daya Nadamuni, senior analyst for design and engineering software at Gartner Inc., Wind River also protects applications with VxWorks AE, its high-availability RTOS that implements a method called protection domains. “Each domain is protected, and you cannot overwrite the memory or an existing task. It gives you more protection from RTOS failure.” However, Nadamuni said that application data, which resides in shared memory, remains unprotected, a fact that she said is “true of most operating systems.”

Donn Rochette, vice president of engineering at embedded systems developer OnCore Systems Corp., said that while the concept of protection domains provides a modicum of security, it also introduces a few problems. “Now that you’ve erected these walls, you’ll end up copying data between what you’ve just protected, because all threads assume that memory can be shared between threads.” He said this exacts a performance toll that is difficult to predict. To help maintain determinism, “Wind River uses a shared common area [of memory], and any [application] can read and write all that data,” essentially removing all protections from the data, he said.

According to Rochette, the OnCore OS solves these problems with a virtual memory model that does not permit applications to map directly to memory. Instead apps are given a virtual memory map equivalent to the total memory available in the system, and the RTOS maps the virtual addresses to physical ones. Applications register themselves with the operating system and can be available only to certain other applications or services. “The military loves this. You can have encrypted and nonencrypted sides, each with no knowledge of the other,” he said. All physical memory is managed only by the operating system; applications are never permitted to touch it directly. “I can put whatever memory I want behind a virtual address. I can have [variables] A and B both going to the same page of memory because I can pick both virtual addresses and point them to the same physical address,” effectively exchanging data between applications without copying, he explained.

Wind River’s Gordon said that while systems with protected memory can help minimize the impact of malicious code, they cannot totally prevent it. “A good hacker will be able to find a way to cause some harm from such an exploit,” he said, adding that the best security plans use a combination of elements. “Ensuring the security of an embedded system is really a joint effort [among] the RTOS developer, middleware providers and the application developer. From the RTOS perspective, this will likely mean more validation of system calls, and increased use of desktop-like kernel/application separation.”

Such combinations of security measures are particularly valuable, Gordon continued, in systems that might require field upgrades. “Any communication with the outside world is a vulnerability,” he said, adding that the most risky are those that allow software to be uploaded to the CPU.

Gordon suggested several limitations. “Only accept uploads from a specific physical connection or perhaps only from internal networks, and use a call-back scheme” to facilitate the device pulling software to it, rather than pushing uploads to the device. He also suggested the use of hash tables for validation of trusted binaries before loading and execution, encryption of uploads and use of administrative accounts.

Most agree that use of such methods could further safeguard embedded systems, but that the RTOS itself has to be its own bastion for protecting the system. “I think to a large degree it depends on the technology,” said OnCore’s Rochette. “If security is defined as [an RTOS] that does not permit a rogue application to crash the box, then surely Linux is much more secure than VxWorks. Security has more to do with the technology that the operating system is based on than [whether] it came from commercial, open or homegrown source code.”

But Weinberg held fast to his open-source viewpoint. “What the industry suffers from is a misunderstanding of openness and security. The misconception is that if it’s open, it’s not secure. Very good locks are understood, but that doesn’t make them less secure.”

Copyright © 1999-2001 BZ Media, LLC