Security Issues

Overview of Security Issues

The KOE provides an environment for the safe execution of Knowbot Programs at remote service stations. This release of the Knowbot system, however, does not address many security issues. This section reviews some of these issues and describes the risks users of the system face.

To summarize briefly: We have made reasonable efforts to protect the host computers that run KPs from attack, but the KOE itself has few security mechanisms. An attacker can damage other KPs, but not the hosting computer.

Security mechanisms are used to control access to objects in the system. We use the term safety to encompass a wider range of issues including the integrity of the system despite accidental failures in individual components. The ultimate goal of these mechanisms is to enforce a security policy, defined by a particular set of rules for a particular system.

Security and safety for mobile agents system is an active area of research both at CNRI and elsewhere. Although the security mechanisms in the current release are limited, these mechanisms will evolve with subsequent release and many or all of the issues discussed here will be addressed.

We'll consider two different parts of the KOE separately in our discussion of security -- an individual service station environment and the system-wide shared components like the namespace. The rest of this section discusses specific concerns for these components; it focuses primarily on potential violations. We divide security violations or attacks into three standard catergories: unauthorized release of information, unathorized modification of information, and denial of service.

In the current system, a stop-gap access control mechanism based on trusted hosts or domains is implemented with checks on IP names and addresses (which can be spoofed). This limits the hosts from which essential requests like KP submission or kill requests and worldroot peer connections are accepted to those whose host name or IP address matches a pattern specified in the config/access.conf file. Not every type of request is checked, though -- in particular, namespace lookups are not checked.

Knowbot Service Station

A service station faces attacks from the Knowbot Programs it runs and from attackers, either KPs or external processes, that locate its Administrator or Receiver objects using the namespace.

The service station runs untrusted Knowbot Programs in a controlled environment that limits the operations that a KP can perform and the resources it has access to. Python's restricted execution environment removes operations that are deemed unsafe, e. g. reading and writing files on the host machine. (See KP interface documentation for a detailed discussion.)

The restricted execution environment places a strong restriction on what information a KP has access to. KPs can't read or write files in the filesystem, which limits the attacks based on unauthorized release or modification of information. There are four ways a KP can access local information:

• via the namespace
• via a plugin process
• via the Administrator and Receiver objects
• via the urllib proxy

The urllib proxy allows KPs to contact Web servers (or anything else that uses the HTTP protocol). A KP could connect to private local machines, posing as a user in the local domain, unless the config/access.http.conf prevents the connection.

A denial of service attack is probably the most significant risk the KSS faces in the current system. The restricted execution environment does not control a KP's usage of resources like CPU time or memory. As a result, a KP could allocate large amounts of memory or run in an endless loop, wasting memory or CPU time and taking resources away from other processes.

Namespace

There are no security mechanisms in the namespace, which makes it another easy target for attacks. The scramble KP in the examples directory demonstrates one kind of trouble a KP can cause by attacking the namespace. Future versions of the system will include a namespace with access control. Until then, there are many places to attack the system via the namespace that can cause KPs and plugins to fail.

Unauthorized release of information:

• The KSS namespace contains an entry for every KP, plugin, and connector. Anyone can monitor what programs are running and what services are available.

Unauthorized modification of information:

• Modifying (including adding) bindings in "/kos" to mislead or capture KPs, or even act as a man-in-the-middle between a reporting station and a valid Receiver.
• Modifying bindings within a conditions or services contexts, which could be misleading or could cause ILU exceptions.
• Directly access the Receiver object, including its KillKP() method.

Denial of service:

• Denial of service can occur when an attacker modifies the namespace so that name that are expected to be valid fail. For example, unbinding the services context of a KSS will cause all lookup_service calls to fail.

The distributed namespace managed by the worldroot servers can also propagate problems at one location to all other service stations. For example, if a KSS becomes disconnected from its peers and a user runs nslist -c, nslist may remove bindings from the namespace. When the KSS re-connects -- specifically, when the worldroots re-establish contact -- the removals will be propagated to all other worldroots. Thus, a functional KSS may find its entry in the namespace deleted by some other KSS.

A worldroot server will always run with the same SBH, even if it is killed and restarted. As a result, an attacker could guess the SBH of a worldroot running on a particular host and try to connect to it as a peer (though the config/access.conf file may disallow this based on the attacker's host name or IP address).

In general, all users of a shared namespace need to trust each other. Furthermore, errors in programs and careless use of tools like nslist can cause problems regardless of whether the users trust each other.