A major point of this paper is that it is feasible to use system-call delays to stop intrusions in real-time, without prior knowledge about what form an attack might take (unlike signature-based scanners). The three example exploits help show that pH can do this, even for very different types of attacks. However, in practice pH's effectiveness is determined by whether it can obtain stable normals for the binaries on a system. Currently, pH can do this automatically only for programs which are relatively simple and are called on a regular basis; even then, there is an ongoing risk that pH could be trained to accept intrusions as normal behavior. Research still needs to be done on more effective training heuristics that minimize the time for pH to obtain a normal profile, but also minimize the chances of pH tolerizing truly abnormal behavior. By incorporating such heuristics into a pH control daemon, we should be able to minimize the need for user or administrator intervention.
It may be necessary to implement a default timeout mechanism through pH, in which any process that is delayed beyond a certain point is automatically terminated. It may also be necessary to increase pH's repertoire to include actions such as system call parameter modifications. Additional response mechanisms may require computationally expensive analysis algorithms to be added; because abnormally-behaving processes are delayed, pH actually has the time to perform more sophisticated analysis when anomalies are detected. Our philosophy, however, is to wait until such a need arises before implementing additional mechanisms.
A second major point of the paper is to show that system-call monitoring is practical, even when every executing process on the system is monitored simultaneously. pH routinely monitors every system call executed by every process with little perceptible overhead. Thus, we believe that the current implementation of pH is efficient enough to satisfy a wide variety of users.
The current version of pH is not completely secure. pH does restrict use of the sys_pH system call to users who have the kill capability (which, by default is only root); however, there are no checks to ensure that a profile has not been tampered with on disk, or restrictions on user access to profiles -- they are currently owned by root, but readable by anyone. An attacker could use this information to design a less-detectable attack based on the system call usage on the target machine. pH could be used to generate a denial-of-service attack by triggering abnormal (but otherwise benign) behavior in a target program. Also, it may be useful to implement mechanisms to prevent users (including root) from being able to directly modify the stored profiles. Such ``hardening'' of pH, though, should wait until pH's basic functionality has undergone further testing.
In the past, we have emphasized that system call profiling is a suitable technique for monitoring privileged programs. pH in its current form, however, monitors and responds to anomalies in all programs. In the future, we may decide to restrict monitoring to privileged programs; yet, with the increasing use of active content on the Internet, it may also be desirable to have pH respond to anomalies in word processors and web browsers. Some large programs such as netscape are implemented using userspace threads, causing system calls to be interleaved in apparently random patterns due to variations in thread scheduling; thus, the system call profiles of these programs may never stabilize. We believe, though, that this will be less of a problem in the future, as programs switch to using kernel threads. Because the Linux kernel uses the same data structure to represent threads and processes, pH is able to monitor kernel threads individually, avoiding interleaving effects.