Fred Cohen & Associates

SetUid and SetGrp Problems

Copyright(c) Management Analytics, 1995 - All Rights Reserved

Copyright(c), 1990, 1995 Dr. Frederick B. Cohen - All Rights Reserved

The Setuid and Setgrp protection bits are particularly useful for avoiding other protection problems, and particularly dangerous because they grant privileges that can potentially be abused. In many cases, the only way to allow multiple users to access a common area of storage without exposing them to leakage, corruption, or denial of services attacks, is to have a program that can mediate access on a case by case basis. This is where a setuid program comes into play. For example, the ``mail'' directory is owned by the ``mail'' user, and the ``mail'' program is a setuid program owned by ``mail''. This allows the ``mail'' program to control access to mail belonging to other users.

Problem:

The problem with setuid programs is that they are granted all rights of the owner or group, and pass these rights on to any subprocesses they create. For example, suppose the ``mail'' program forks another process to invoke a program called ``deliver''. If the ``mail'' program is not carefully written, an attacker could create an executable program called ``deliver'', put it in the beginning of the search path, and cause the Trojan horse ``deliver'' program to be executed with the rights of the ``mail'' user.

Prevention:

We can prevent setuid programs from being created by limiting the capabilities of the Chmod system call. Most installations are unwilling to modify the system in this way.

Detection:

It is common to have an Sh script that is executed every night to search for setuid and setgid programs. They are listed for the systems administrator who is supposed to advise or control users who use this facility.

Cure:

The cure is a two edged sword. We can simply remove the setuid and setgid bits from all files, but then we won't have the system services we might desire. Another technique is to provide a single well controlled setuid facility which the systems administrator manages to provide any facility desired by users.

Problem:

Another variation on this theme is a Trojan horse that creates a setuid program belonging to any user that runs it. Since the user running the Trojan horse has the right to create a setuid program, and a setuid program can extend that users rights to the attacker, any time you run any program, it has the potential of granting any other user all of your rights.

Prevention:

There is no truly effective prevention of this attack.

Detection:

The same detection techniques can be used as stated above. We can also augment the integrity shell used to defend against viruses to look for setuid programs and eliminate the setuid priviledge unless they are authorized, but this is a poor technique in this particular case.

Cure:

If we have a list of authorized setuid programs, we can automatically remove the access bits from files not authorized to have this capability, but this is rarely a practical defense against a serious attacker.

Problem:

This is particularly serious for the superuser. If the superuser ever runs an external program, the entire system could be completely and eternally compromised by that action. For this reason, it is critical for the superuser to be very careful about running programs or allowing the path to be set improperly.

Prevention:

The superuser can and probably should have a more restrictive form of command interpretation than the average user. An example is a special form of Sh that refuses to allow the superuser to run any program not owned by the superuser.

Detection:

Detection is the same as in the above cases, except that the superuser is far easier to control because there are relatively few legitimate changes, and because the systems administrator can legitimately make all of the appropriate decisions without interfering with user rights.

Cure:

Cure is simply a matter of resetting the appropriate bits. Tracking down the source of the attack is far more difficult, if not impossible. We may look at the list of all programs executed since the protection bits were last known to be correct and try to use this to track down candidates for the attack (via the `lastlog' program). This is somewhat complex and requires a number of attacks in sequence in order to be effective, but can be done if you are patient and knowledgeable enough.

Problem:

Deamon processes are often used to provide shared access to system facilities. The paging deamon, mail handler, printer spooler, and alarm system are typical examples of facilities sometimes handled by deamons. Deamons are susceptible to all of the difficulties we have described, but in addition, they are generally operated with special privileges in order to provide their service while maintaining protection. As a result, a failure in a deamon can often be exploited to avoid protection.

Prevention:

You can prevent demons from causing problems by only using them when necessary, and designing them well so that these problems occur very infrequently.

Detection:

There is no systematic method for detecting security problems caused by deamons.

Cure:

Without detection, cure is rarely affected.