Two Main Reasons for Vulnerabilities

Recall from earlier discussions that systems are usually compromised for one of two reasons:

•  Improper configuration by the vendor or by an administrator

•  Software bugs in software you purchase and in software you develop

Even the best preventative security tool will not meet your expectations if improperly configured. Firewall scans by consultants and security organizations such as ICSA show that incorrect configurations do indeed occur. It also seems that software bugs will be with us forever. A reasonable plan for defense is to conduct periodic reviews of configurations along with source code reviews.

Modules that should especially be examined for bugs include those that provide network communications for other nodes and those modules that run with special privileges. Your code reviews should look for the following:

•  Buffer overflow problems

•  How resources are created, read, written, and destroyed (object reuse)

•  Improper default assumptions, such as assuming the order of two events

•  Handling of data input values, particularly assumptions about character content and length

•  Adherence to the least privileged principle for blocks of code

If you obtained the software, such as your operating system, from someone else, chances are you do not have the source code (nor should you accept the code review as your problem). In the examples that follow, you will see how program flaws such as those itemized in the preceding list can open your system to intrusions. The next few paragraphs give you an overview of what can happen if software contains one of these bugs.

Buffer overflow attacks have been mentioned several times in this book already. The problem is that a program makes some incorrect assumptions about the length of a value input by the user or passed by another program. The interesting case occurs when the flawed program runs with special privileges. A buffer overflow will result in the system running an arbitrary set of instructions that the hacker supplied along with the input data. The famous Internet Worm used this as one of its techniques.

Another incorrect assumption someone can make when programming is the order of two independent events. Hacks that exploit this weakness include race condition attacks. Well-known examples include file handling. UNIX systems check only access control for the initial file open or create. Because instructions are not atomic, you can use symbolic links or world-writable permissions to substitute a file before the read or write operations occur. A common attack is to trick a privileged program into writing over the contents of a privileged file (such as /etc/passwd) when the program is writing to a world-writable file or directory.

Incorrect assumptions about a process’ UMASK, UID, or GID also can lead to security violations. One common bug occurs when a privileged process creates a resource and does not explicitly set the permission bits. The resource is thus not adequately protected from other users on the system. Incorrect assumptions about the length of data can lead to buffer overflow attacks. Improper assumptions about the contents of an input field lead to hacks such as concatenating arbitrary commands on to the end of the input data. The receiving program that runs the system() command on the input string thus is tricked into executing extra commands.

Finally, violations of the least privilege principle are all too common. The programmer errs by running too much of the program with escalated privileges. The proper approach is to run only a few necessary statements with additional privileges, while setting the minimal privileges for the program as a default. The more instructions a program runs as a privileged user, the higher the probability that a hacker will find a hole to sneak through.

Notation

For the purposes of this discussion, it will be assumed that you are using a system monitoring tool that can detect events and important attributes about those events. As noted in previous chapters, the audit logs of most systems will capture many details about system activities. Instead of giving specific listings of what the audit logs would look like for each UNIX OS you might be interested in, this chapter will give a pseudo description of what to look for in the logs. Indeed, if you have a sophisticated monitoring tool, such as Stalker or CMDS, you will not be looking at raw audit logs but will see a more meaningful interpretation of them in report form.

If during one of the following sections, you need to detect an attack by searching for a specific file delete event, you might be given a recommendation to look for audit records with the following:

•  AUID = any value

•  RUID or RGID = any value

•  EUID or EGID = any value

•  FILE_Delete audit event

•  File or resource name

Other details you probably would see from Stalker or CMDS for such an event would be the file’s inode value, it’s creation date, last modification data and time, and other values you might need for investigating the event further.