Programming mistakes in set-uid programs have been a real source of security headaches. A single security hole in just one set-uid root program can be all that is needed for an attacker to gain root access.

The problem is widespread. We're not talking about one or two isolated instances—more like a graveyard of broken set-uid programs. Again, check the SecurityFocus.com vulnerability database for set-uid problems—there have been hundreds (thousands?)! The problem isn't going away, either—especially in third-party programs. New set-uid vulnerabilities are being reported to Bugtraq on a weekly basis.

Writing secure set-uid programs can be difficult. Just because you can program C doesn't make you a security god. Heck, even the security gods get it wrong sometimes.

The C language is pretty unforgiving to the developer of set-uid programs—C makes it too easy to screw up and open the barn door. Specifically, the lack of bounds checking in C has allowed many developers to write programs with buffer overflows.

However, it would be pretty lame for us to blame a language for set-uid problems. After all the security pitfalls of C are well documented—it's hardly a new language. Alas, the biggest source of security vulnerabilities is the näive programmers slapping together code they think is secure.

A typical UNIX distribution ships with a large number of set-uid root files—averaging between 70 and 100. Now, not every line of code necessarily runs with root privilege—the privilege has to be invoked by the program via a call to set-uid. But, even if the privileged lines of code are written super securely, a wily attacker can exploit a hole in the nonprivileged section of code (that is, before the call to set-uid) with devastating consequences. If the attacker exploits a buffer overflow and can force the program to make a call to set-uid—boom, game over. Any code the attacker can supply for the program to execute will run with root privileges.

Security-savvy programmers throw away the set-uid privilege as early as possible in the program.

So, given the number of privileged programs, the administrator is left to ponder: "Where will the next vulnerability be found?" The answer is, we simply don't know. Hence the stock advice of any security textbook is to remove the set-uid bit from unnecessary privileged programs. This is much easier said than done. How do you know what is unnecessary? Sure, you know programs like passwd need to be set-uid, but what about all those others? Removing the set-uid bit has to be done with a great deal of care—unless you want to have a lot of free time on your hands.

A classic example of irrelevant set-uid code (at least for most people) is the KCMS (Kodak Color Management System) suite of programs. These are installed during a full install of Solaris and set-uid root. The CERT advisory CA-1996-15 describes KCMS as

…a set of Openwindows compliant API's and libraries to create and manage profiles that can describe and control the color performance of monitors, scanners, printers and film recorders.

So, if you are a Solaris admin, have you ever used those? The only time I have used them was to demonstrate to system administrators how easily root could be compromised.

Another more common example is the ping program. Ping sends an ICMP ECHO REQUEST packet to a remote system and waits for a response (ICMP ECHO REPLY) to check whether the remote system is alive (although not necessarily functioning). The standard implementation of ping requires a raw socket to be able to build the ICMP ECHO REQUEST packet. This is a privileged action because having access to a raw socket means you can create custom packets—very dangerous in the wrong hands. So the ping command is set-uid root.

Unfortunately, allowing mischievous users access to seemingly innocuous programs like ping can result in a security nightmare. Remember the Ping of Death? The ping command has an option whereby the user can control the size of the ICMP packet sent. It turns out that some implementations of ping allow users to send out very large ping packets that have caused remote systems to crash. Was anyone expecting that? Of course not. Hence the need to follow the least privilege principle. Only allow users to run what they need to run in order to do their job. Does every user on every system really need to be able to run network diagnostic tools?

Then there are those set-uid programs that don't even need to be set-uid—typically, system administration commands. The set-uid bit is redundant if only root is running it.

I am not aware of any vendors that provide any guidance, or sufficient technical program documentation to help an administrator easily identify nonessential set-uid programs.

Fortunately for Solaris and Linux users, there is some good information out there on locking down your set-uid programs.

So, how do you minimize your system's exposure to set-uid holes that are waiting in the wings?

1. Try to avoid installing the full distribution—install only what you need. This is a security best practice. If the code isn't on your hard drive, then no one can use it against you. But this can be hard to fulfill in a pressure-filled environment where the focus is on getting things live. Just remember the costs of post-live lockdown.

2. List all the set-uid/set-gid programs on the system. You can do this with the following commands:

3. find / -perm -u+s -print

4. find / -perm -g+s -print

5. Find out the stated purpose of each program. You're likely to find that some of them are totally unnecessary—neither you nor your users would ever need to run them. As long as these programs are not required for system operation, they can have the set-uid bit removed, or, alternatively, all access by Other can be removed (that is, chmod o-rwx file).

6. Identify the set-uid root programs that only root needs to run and remove the set-uid bit—they don't need to be set-uid because you'll be running them as root. There's no point in leaving potential time bombs lying around for someone to play with. Remove the set-uid bit or access by Other (either is good). This can eliminate a large number of programs.

7. Identify set-uid programs that leak sensitive system information and thereby make an attacker's life easy—for example, ps, top, and netstat. Ps and top display process information, including command-line arguments—these can contain application usernames and passwords. They also help an attacker identify usage patterns, which assists timing of attacks. Similarly, netstat reveals information about your network topology (via the -R switch) and current network connections (that is, who is talking to your system).

This kind of privacy disclosure can lead to client systems being attacked. Client systems are soft targets, the "low hanging fruit" of the network. They can be used as remote password sniffers (to compromise accounts on more systems), proxies to misdirect attack investigations, and conduits to other network segments that are unreachable directly (that is, they are behind a firewall or not directly attached). It's not hard to imagine the consequences if the client victim happens to belong to the system administrator level.

So limit access to "leaky" set-uid programs on a strictly need-to-have basis. The side message is to secure your clients machines—they can be used against you!

8. Identify the set-uid root programs that only a trusted group of users need to run (for example, network operations). Create a dedicated UNIX group and enroll the trusted users in this group. Next, change the group ownership of the set-uid programs to this group (don't change the owner though because that would make the set-uid call fail). Finally, and very importantly, remove all points of access by Other (that is, chmod o-rwx file). These include print queue management programs, network utilities, and application management interfaces.

9. Identify the set-uid root programs you think no one will ever need. Before you remove a set-uid bit, you need to be totally convinced you won't break something. In cases like these you need to profile the programs'uses—that is, to log program invocation. One approach is to install an AUSCERT wrapper like the one discussed earlier. But, here, we're not going to use the wrapper for its intended purpose (although there is nothing stopping you from doing so). Instead, we're going to modify the wrapper to make a call to the logger command before the real program is called. This is unnecessary if you have C2 auditing configured and are logging calls to exec(). Review your logs after a month, and, if no relevant activity has been logged, then you probably have sufficient basis to remove the set-uid bit. You might want to leave your pager on for a while, though.

10. You should now be left with a handful of set-uid root programs that you consider essential. Modify the AUSCERT wrapper for those programs to make sure overly long arguments or environment variables cannot be specified. This won't protect you against all attacks but will protect you against some the common ones.

Pat yourself on the back—you've made it a lot harder for an attacker to succeed against your system.

Maintenance wise, you will find that vendor patches assume a vanilla install, and, therefore, patches and upgrades clobber your changes. Always run a file integrity checker after applying updates to identify changes—that way, you avoid your efforts being undermined by dumb scripts.

Make sure you keep an eye on Bugtraq to keep up with new set-uid exposures, and subscribe to your vendor's security alert mailing list to ensure that you hear about patches quickly.

If you have only a few trusted users on the system, you might be tempted to skip the whole set-uid removal process. Before you do, consider this: You are unwittingly making life easier for a remote attacker. If an attacker gains shell access to your machine through some 0-day (new) exploit, she will use any vulnerability she can find to elevate her privileges to root. Set-uid root programs will be at the top of her list. If you fail to bolt down your set-uid programs, an attacker will not hesitate in leveraging this against you.

Understand, though, that gaining root is not always the attackers'endgame—it depends on what they are trying to achieve. For example, you can store all your sensitive company data in a relational database that is owned by a user called "datamart." Clearly, the attacker only needs to target the data owner account (or privileged application accounts) to get full access to the database. This can be through password guessing, social engineering, or exploiting security bugs in set-uid application programs. Don't focus on root to the exclusion of your primary application accounts.

Application software often ships with set-uid/set-gid programs. In my experience these tend to be rife with problems—ignore them at your peril. It is rare to find security savvy application programmers.