Security Watch

Will Vendor Security Measures Lock Out Free Software?

Technologies like Trusted Computing could lock consumers into their hardware products.

• By Russ Cooper
• 02/27/2006

Trusted Computing technology is no longer about security. It's about a distant person or entity being able to trust the behavior of your hardware in ways they care about. It's like having a rootkit on your system, only worse. Those who the hardware trusts to modify its code would be able to do so…worse, be able to dictate that the hardware must do so. This is not unlike the situation we have today with satellite TV boxes or cell phones.

While control of the device is passed to another -- someone other than you -- use of the device is still within your control. For example, a corporation may wish to use Trusted Computing technologies to ensure that their assets (e.g. the laptop they give you to perform your job on) are used purely for their intended purposes.

Certainly, IRT is a serious concern for the average consumer. If you discovered today that the e-mail system you've been using for the last five years will not let you move your archived e-mail messages to some new provider, you'd be understandably upset. Trusted Computing technologies could bring such a situation about -- this is already true of, for example, voicemail systems of most telephone providers. The same is also true of TV providers such as EchoStar. With these devices, for many years consumers have been accepting these limitations, or at least understanding their use of devices must be constrained by such limitations.

Moving this technology away from single-purpose devices (like TVs or cell phones) to the average personal computer might seem frightening to some, especially if they were in the business of promoting "free" environments. One might be happy to have a PC that incorporates Trusted Computing to allow you to watch and record TV, or play music, while at the same time wanting to ensure it has nothing to do with the contents of your e-mails or online gaming. The concern really comes from the scope the Trusted Computing will involve itself in on your system, its ability to accept your control of its use (or abuse), and the offerings that will be made available as a result of it being present on your system.

As with so many things, the market will decide.

Intellishield ID: 10342 - Oracle PL/SQL Gateway Privilege Escalation Vulnerability: By simply passing a ")" character or its hexadecimal equivalent (%29) to the Oracle PL/SQL Gateway (which is a component of the Oracle HTTP Server), it's possible to bypass the PLSQLExclusion list. This list represents the functions that connections from the Internet are permitted to execute. Bypassing of the list allows remote criminals to execute privileged commands, thereby creating the possibility to perform actions otherwise limited to the Database Administrator (DBA) account. Patches are currently unavailable.

Simply filtering URLs permitted to reach your server will prevent the invalid placement of both the ")" character and a privileged function. Relying on a simple mechanism such as the PLSQLExclusion list alone begs for problems such as this to occur. As complex as URLs may get, any good Web site designer must comprehend the importance of ensuring that the URLs their server process sees must be parsed by them to ensure their validity. Doing so would prevent, for example, any URL containing any privileged function execution attempt, regardless of the contents of the PLSQLExclusion list. The Cybertrust motto is "by default, deny," which means use an inclusion list, not exclusion.

Malicious Code
David Aitel, principal researcher at Immunity, believes security professionals should consider the use of beneficial worms, or nematodes as he calls them, to gain better insight into their networks. He raises the discounted theory with some new twists, such as having the worm verify that it should attack a given system by contacting a central server for permission. Further, he proposes that the worms be created automatically, rather than by hand, to ensure the quality of the code the worm contains.

His emphasis seems to be on shifting scanning from a single device, usually controlled by an administrator to self-propagating code launched on your network so as to run peer-to-peer. In this way the entire network could be scanned, even systems that aren't expected to be present. Using a central scanner often leaves the scanning only to systems that are known to exist.

In my opinion, the risks of this approach seriously outweigh any potential benefits. In theory, if the "good" worm were to spread beyond your corporate network, it would no longer be able to probe the central server for permission to attack other systems, thereby shutting it down. Of course, it would be trivial to place bogus permission servers on the Internet and recode so-called "good" worms to probe these malicious permission servers. The result would be that security professionals would essentially be creating worms for the criminals to modify and use for their own purposes…hardly a beneficial situation.

While Aitel acknowledged that testing so-called "good" worms is difficult, he believes it's possible. However, historically lack of knowledge about the environment a worm is going to run in coupled with unexpected behavior in that environment has meant that even testing can have disastrous effects.