Dangers of SUID Shell Scripts

Thomas Akin

This article attempts to walk the fine line between full disclosure and published exploits. The object of this article is to illustrate how SUID programs work in order to help others writing their own programs avoid some common mistakes. The examples I provide are detailed enough to help you understand each danger, but I don't promise that all will work exactly as demonstrated if you try to use them maliciously. (sidebar)

Normally, UNIX scripts and programs run with the same permissions as the user who executes them. This is why typical users can't change their passwords by editing the /etc/passwd file; they don't have the permission to write to /etc/passwd, and no command they run will either. SUID programs, however, override normal permissions and always run with the permissions of the program's owner. Therefore, users can use the /usr/bin/passwd command to change their passwords. The /usr/bin/passwd command is SUID and is owned by root. It always runs with the same permissions as root.

When new administrators discover SUID, they often see it as a silver bullet that will solve all of their problems. They immediately begin using SUID scripts and programs to make their jobs easier. Unfortunately, they usually do it wrong.

When working with admins new to SUID, I often encounter scripts like this:

% ls change-pass
-rwsr-x---   1 root     helpdesk   
    37 Feb 26 16:35 change-pass

% cat change-pass
#!/bin/csh -b
set user = $1
passwd $user

This simple script was set up to allow the help desk reset user passwords, which is a common need. The script is SUID root and is only executable by root or the members of the help desk group. This simple script is also riddled with holes.