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

Lesson One -- Never use C-shell for SUID scripts.

% cat change-pass
#!/bin/ksh
user=$1
passwd $user

% export PATH='/tmp'
% echo "cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4755/tmp/sh" >/tmp/passwd
% ./change-pass

Lesson Two -- Always manually set the PATH and use absolute path names.

% cat change-pass
#!/bin/ksh
PATH='/bin:/usr/bin'
user=$1
/usr/bin/passwd $user

Lesson Three -- Understand how the programs in your script work.

% cat change-pass
#!/bin/ksh
PATH='/bin:/usr/bin'
user=$1
rm /tmp/.user
echo "$user" > /tmp/.user
isroot='/usr/bin/grep -c root /tmp/.user'
[ "$isroot" -gt 0 ] && echo "You Can't change root's password!" && exit
/usr/bin/passwd $user

% cat change-pass
#!/bin/ksh
PATH='/bin:/usr/bin'
user=$1
[ -z $user ] && echo "Usage: change-pass username" && exit
rm /tmp/.user
echo "$user" > /tmp/.user
isroot='/usr/bin/grep -c root /tmp/.user'
[ "$isroot" -gt 0 ] && echo "You Can't change root's password!" && exit
/usr/bin/passwd $user

Lesson Four -- Don't use temporary files! If you must use temporary files, don't put them in a publicly writable area.

% cat change-pass
#!/bin/ksh
PATH='/bin:/usr/bin'
user=$1
[ -z $user ] && echo "Usage: change-pass username" && exit
[ "$user" = root ] && echo "You can't change root's password!" && exit
/usr/bin/passwd $user

% cat change-pass
#!/bin/ksh
PATH='/bin:/usr/bin'
user=${1##*[ \\$/;()|\>\<&    ]}
[ -z $user ] && echo "Usage: change-pass username" && exit
[ "$user" = root ] && "You can't change root's password!" && exit
/usr/bin/passwd $user

Lesson Five -- Distrust and check all user input, and strip out any meta-characters.

Lesson Six -- Always manually set your IFS.

% cat change-pass
#!/bin/ksh
PATH='/bin:/usr/bin'
IFS=' '
user=${1##*[ \\$/;()|\>\<&    ]}
[ -z $user ] && echo "Usage: change-pass username" && exit
[ "$user" = root ] && "You can't change root's password!" && exit
/usr/bin/passwd $user

% cd /tmp
% ln -s change-pass rootme

% ./rootme &
% rm rootme && \
  echo "cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4755 /tmp/sh" \<BR>
    >> rootme

it is possible to run anything as root. Done like this, there is only a small chance the attack would succeed, but there are techniques and programs to increase the chances of success and to automate the procedure for you. There are only two defenses against this attack. First, do not use SUID shell scripts. Second, some systems (e.g., Solaris) prevent this race condition by passing an open file handle to the new shell, thus avoiding the need to reopen and read the SUID file.

Lesson Seven -- Don't use SUID shell scripts.

Even after all our work, it is nearly impossible to create safe SUID shell scripts. (It is impossible on most systems.) Because of these problems, some systems (e.g., Linux) won't honor SUID on shell scripts. If you need the functionality of SUID, there are three more secure options. A wrapper program written in C, a Perl script, or a program like sudo. If you are new to secure programming, I recommend either sudo or a Perl script. SUID Perl scripts have built-in protection to prevent programmers from making the mistakes addressed in this article. For more information on secure SUID programming, see Practical UNIX & Internet Security (O'Reilly & Associates), or visit: http://seclab.cs.ucdavis.edu/~bishop/ \ secprog.html.

Thomas Akin has worked in Information Security for almost a decade and specializes in UNIX, Network, and Internet security. In addition to the CISSP, he has four UNIX and three Networking certifications. Most of his time is spent developing Information Security training programs, teaching, and writing. He can be reached at: [email protected].