Specification-based Techniques

Specification-based intrusion detection systems employ specifications that describe the valid behavior of programs to detect intrusions. In particular, programs in execution are monitored for violations from the corresponding valid behavior specifications. One useful type of specifications is the set of valid operations of a program [7]. We have encoded the specifications for several programs (e.g., imapd, fingerd, lpr, lprm, ftpd, httpd, etc.) describing their valid operations as ID wrappers using WDL. Each specification-based ID wrapper is configured, using the activation criteria, to wrap the execution of the program with which the specification is concerned. We found that the WDL itself is very suitable for expressing the set of valid operations of a program.

  

Figure 3: Partial imapd program behavior specification in WDL

Figure 3 shows part of a specification of the imapd program, encoded in WDL, that is concerned with the valid parameter values of open-read, chmod, fchmod, and execve operations. The first clause specifies that after a successful open system call with the read-only flag on (lines 1-2), the action block (lines 3-7) will be executed. The action block obtains the inode information of the opened file and checks whether 1) it is world-readable, 2) owned by the invoker, or 3) created by the program execution (checked by the local function created()). It raises a violation if all conditions are false. In short, the first clause detects any bad open-read operation: on a file that is neither publicly readable, owned by the invoker, nor created by the program execution itself. Similarly the second and third clauses raise a violation if the program performs a chmod/fchmod operation on a file not created by the program execution. The last clause specifies that the wrapper intercepts the execve system call before it executes, issues a violation, and prohibits the call by returning an error code to the caller immediately ( return WR_D_BADPERM). The partial specification illustrates that criteria for event interception can be specified very easily in WDL. In addition, accesses to system call parameters can be accomplished easily through special $ variables. For example, the $path variable on line 10 denotes the path name of the file in the chmod system call. A reference or assignment to a variable effectively reads/modifies the corresponding argument of the intercepted system call. WDL also handles the copying of argument data between user space and kernel space automatically, allowing wrapper developers to focus on the key aspects of a wrapper instead of low-level programming details. With ID wrappers, we can monitor programs for improper modifications to objects that otherwise cannot be accomplished using traditional audit trails. In particular, ID wrappers can examine data read/written to specific files without a huge overhead. Using this capability, we wrote an ID wrapper that examines the passwd program to ensure that when a user (say Joe) invokes the passwd program, the program modifies only the part of the password file associated with the password of Joe. If there is a vulnerability in the passwd program that allows the attack to control the program to arbitrarily modify the password file (e.g., changing the user ID of a user), this ID wrapper is able to detect such an attack.