Exploiting Software Vulnerabilities

I l @ ve RuBoard

This area has the most successful attacks on systems. Almost daily there are reports of new bugs, or variations of old bugs , in system software. Patches for repair are released as soon as the bug is discovered . However, many system managers do not keep current on operating system releases and applying patches, especially security patches.

Because this is changing on a daily basis, it is not possible to give timely information pertaining to software vulnerabilities in a book. By the time the book is printed and distributed, the problems discussed will have been repaired and an entire new crop of problems will exist. However, we will take a look at some "classic" software vulnerabilities and software attacks that are not based on bugs.

PATH Variable Attacks

PATH variable attacks are based on the fact that many programs are dependent on your path variable to locate subprocesses that are required for the program. This allows the program to be independent of the path name of the directory where it and its child processes reside. This includes both programs and scripts.

If a hacker can read your scripts or has read permission to your binaries so he can use the strings command on them, he will be able to locate programs that are executed with either a relative path or no path, thereby depending on the path variable. Shell scripts and programs should execute programs using a fully qualified path name only. Short of this, they should set the PATH variable themselves , eliminating the dependency on an appropriately configured user environment. Removing the read permissions from binaries and scripts will make it more difficult for the hacker to utilize this method of attack. Some implementations require that read permissions be allowed to execute a shell script.

File Name Attacks

File name attacks are instigated by creating a file whose name will be interpreted by the system as something else by embedding command delimiters into the file name. Since UNIX systems have no restrictions on what characters can be used in a file name, you can insert terminators and spaces into a file name. For example, a file could be called

 core;rm -r /* 

Even if this file is discovered, just getting rid of it could be perilous. If this file is processed by any command that uses the shell to expand the file name, the semicolon will be interpreted as a shell delimiter and the part of the file name that follows the semicolon will be interpreted as a command. In the previous example, the command after the semicolon is the command to delete all the files on the computer. It would be devastating if this command were run by the superuser.

File attacks are especially effective for systems that are fairly well managed. These systems that have a good system manager, who may not be a great security manager, will have automated many of the repetitive tasks , such as deleting core files, consolidating log information, and so on. Most of these activities will have been automated using cron, so they are done on a regular basis. And some of these jobs will be run as the superuser.

cron

Cron allows for time-based scheduling of jobs. Many of these scheduled processes will run with superuser privileges or with other special privileges. In System III-based systems, all cron processes are run by root and are stored in the file /usr/lib/crontab . In System V-based systems, each user can have his or her own cron processes; these are stored in files with the name of the user in the directory /usr/spool/cron/crontabs .

This is a prime location for hackers to gain more privileges and to check to see if automated system monitoring exists. Jobs set up in cron to monitor logs and gather other information are a prime signal that the system is being monitored . A hacker can use permission problems with the cron jobs directory or with any of the processes started from cron to substitute his own process and gain the privileges of that job.

One of the major advantages that a system manager has over an outside hacker is the knowledge of his system. It is important to know what your system's cron jobs are and what they do. You should periodically check the permissions on both the crontab files and the programs they execute.

There are also two permissions files used by the cron system. The first permission file is /usr/lib/cron/cron.allow . If this file exists, then all the login names listed in the file are allowed to use the cron system. If this file does not exist, then the second permissions file, /usr/lib/cron/crontab.allow , is used. If this file exists, then all users except those listed in the file are allowed to use the cron system. If neither file exists, then only the superuser can use the cron system.

at

The at command is similar to the cron system; it allows you to schedule a job at a specific time in the future. The System III Version runs an associated program, atrun, that is shipped with the setUID bit set. In this case, the system can be subverted using the at command. The System V Version also has two permissions files: at.allow and at.deny . They operate in the same manner as the cron permission files.

I l @ ve RuBoard