In other words, the daemon can perform a number of different sets of two different actions to leak information to your program.

You’re not done with extending this line of reasoning yet. What happens if the daemon is listening to any number of sockets simultaneously? The daemon reads data values Y from N different sockets, reads X from the privileged file, and then it computes some function f(X,Y₁, Y₂, …, Y_N). After this, the daemon returns this value to your socket. Beforehand, you and the daemon signed a pact agreeing on the algorithm so that you can invert the data received on the socket. All of the Y values are meaningless except for yours.

The problem here is that the leaked data is getting more obscure. To make it worse, assume that there are some legitimate f(X,Y₁, Y₂, …, Y_N) computations that the daemon sends to you, those which do not leak information about the privileged file. With this slight twist, the IDS will really have a difficult time distinguishing between legitimate and intrusive behavior. Some theory-minded people would look at this last case and start mumbling terms like intractable. In practical terms, the examples indicate that the more indirection an attacker can introduce into the intrusion, the harder it is to find the path that identifies the events as intrusive.

Taking a few steps back, what happens if your program and the daemon are running on different systems? In this case, the IDS needs information from two systems to keep a path of identity and activities. If the path you took to obtain a login shell traversed several intermediate nodes, then each of these also would need to report activities to a central IDS monitor in order to maintain the path. Tracking activities across multiple systems is challenging. The Distributed Intrusion Detection System (Snapp et al., 1991) was a research system that tried to solve this problem. When you log in into a system, your UID represents who you are. To preserve your activities across UID transitions, the OS assigns an AUID to you. If you run a SUID root program, your AUID does not change. Therefore, auditing can assign accountability for behaviors.

The same type of immutable ID is needed for tracking activities across a network of nodes. DIDS assigned a network ID to the user when the first login event for that user occurred in the network. This assignment was actually made in a batch fashion when the audit logs were processed, but it easily could have been accomplished in real time. DIDS tracked users as they jumped across systems using remote commands. However, it did not track communications activities, such as socket data contents, to find complex attacks such as the scenarios just discussed. No commercial products can detect interprocess hacks in a general way, although some specific attacks are monitored. For example, Ping of Death is an a example of a client-server socket data flow that launches an attack. No commercial product claims an attack signature for detecting when a remote user accesses a local process via a socket and then reads privileged information through that socket.

Is this series of examples really intrusion detection? Well, if the file being read happens to be the shadow password file, the end result is no different from when a user manages to read encrypted passwords via a buffer overflow attack. As hackers get more sophisticated, complicated threats like the ones discussed will increase. The key to success for an IDS is to determine that a path exists. The path must reflect knowledge about data and actions to be useful for detecting intrusions. Success requires tracing this path through a variety of activities on the system.

If you are an intruder who gains privilege in order to read privileged files, you can bet that most IDSs will report that as an event. The more complicated scenarios in this chapter are not handled by commercial products today. The reason is that enough data is not available to the IDS. To detect sequences, such as those presented in this chapter, the IDS needs access to memory locations used by the program as well as very detailed information on instructions executed by the CPU for that program. Not only is the level of detail minute, but for the OS to provide this much information, it would need to emit an auditable event for almost every CPU instruction. If one were really paranoid about covert channel leaks, every CPU instruction and its parameters would need to be logged. This means that each CPU instruction requires several other instructions for writing the audit log. It doesn’t take a genius to see that in this degenerate case, intrusion detection dominates the system’s resources.

Note that in these examples the daemon is essentially an application running on top of the OS, although it has not introduced its own security model (its own subjects and objects). Interprocess communication between programs on the same system is one place where a boundary occurs—between the two endpoints of the session. At a given moment in time, either half of the session is performing services for the other half. When this happens, it is imperative that appropriate security be enforced. As you have seen in previous sections, lax programming practices can lead to problems.