Lecture 11. UNIX Security


11.1 SetUID and its Exploits
11.2 .rhosts and r-commands
11.3 sticky bits
11.4 Buffer overflow
11.5 TCP/IP Protocol Vulnerabilities
11.6 Buggy programs
11.7 Security Tools

11.1 SetUID and its Exploits
 

  • UID (User ID) and GID (Group ID)
  • real user ID and real group ID
  • effective user ID and effective group ID
    • an active process has an effective user ID and an  effective group  ID that are used to determine file access permissions (see below).  The effective user ID and effective  group  ID are  equal  to  the process's real user ID and real group ID respectively, unless the process or  one  of  its  ancestors evolved  from  a  file  that had the set-user-ID bit or set-group-ID bit set
  • setting UID (chmod 4000 path) and GID (chmod 2000 path)
  • Example
    • $ cp /bin/rm .
$ cp rm srm
$ cp /bin/sh .

$ su
Password:
# id
uid=0(root) gid=0(root) ...
# chown root *
# chgrp root *
# chmod 4755
# ls -l
total 318
-wxr-xr-x   1 root     root        10116 Oct 30 14:44 rm
-wxr-xr-x   1 root     root       301272 Oct 30 14:45 sh
-wxr-xr-x   1 root     root        10116 Oct 30 14:44 srm
# ls -l /bin/sh
lrwxrwxrwx  1 root     root            4 Oct 16 22:52 /bin/sh -> bash
# chmod 4755 s*
# ls -l
total 318
-rwxr-xr-x   1 root     root        10116 Oct 30 14:44 rm
-rwsr-xr-x   1 root     root       301272 Oct 30 14:45 sh
-rwsr-xr-x   1 root     root        10116 Oct 30 14:44 srm
# exit

$ id
ud=103(rhee) gid=100(users) groups=100(users)
$ ls -l /test*
-rwxr-xr-x   1 root     root       301272 Oct 30 14:50 /test-file
-rwxr-xr-x   1 root     root       301272 Oct 30 14:50 /test-file2
$ ./rm /test-file
./rm: `/test-file'¸¦ Áö¿ó´Ï´Ù: ¸ðµå 0755À» µ¤¾î¾µ±î¿ä? y
./rm: /test-file: Çã°¡ °ÅºÎµÊ
$ ls /test*
/test-file   /test-file2
$ ./srm /test-file
$ ls /test*
/test-file2    

$ ./sh      # doesn't work in Solaris
# id
uid=103(rhee) gid=100(users) euid=0(root) groups=100(users)
# ./rm /test-file2
# ls /test*
ls: /test*: ±×·± ÆÄÀÏÀ̳ª µð·ºÅ丮°¡ ¾øÀ½
  • shell variable: IFS (Input Field Separator)
  • lpd bug
    • 11.2 .rhosts and r-commands
     
    The /etc/hosts.equiv and .rhosts files provide the  remote authentication database for rlogin, rsh, rcp, and rcmd.  The files specify remote hosts and users that are considered trusted.  Trusted users are allowed to access the  local system without supplying a password.  The /etc/hosts.equiv  file applies to the entire system, while individual users can maintain their own  .rhosts files in their home directories.

    The remote authentication  procedure  first  checks  the  /etc/hosts.equiv  file  and then checks the .rhosts file in the home directory of  the  local user  who  is requesting access.  Entries in these files can be of two forms.  Positive entries allow access, while negative  entries deny access.  The authentication succeeds when a matching positive entry is  found.   The  procedure  fails when  the  first  matching negative entry is found, or if no matching entries are found in either file.  Thus, the  order of  entries  is important; If the files contain positive and negative entries, the entry that appears first will prevail.  The rsh and rcp programs fail if the remote authentication procedure fails.  The rlogin program  falls  back  to the  standard  password-based  login procedure if the remote authentication fails.

    Both files are formatted as  a  list  of  one-line  entries. Each entry has the form:

    hostname [username]
    Negative entries are differentiated from positive entries by a  `-'  character  preceding either the hostname or username field.

    Positive Entries

    If the form:
    hostname
    is used, then users from the named host are  trusted. This form may  be  used  in both the /etc/hosts.equiv and .rhosts files.
  • The feature of  trusted hosts is useful for many purposes:
  • convenient access to remote systems
  • X Window
  • access to remote devices like backup tape drives
    • but an extreme caution should be given; otherwise it can be a serious security hole. It is advised not to use '+' at all.


  • Example of exploit (SetUID, sendmail bug, .rhosts)
  • /usr/lib/sendmail  is owned by root, and has set-user-id bit set
  • some old buggy  /usr/lib/sendmail  creates /var/tmp/dead.letter when it fails to deliver a message.
  • create a file (fake) to be faked as .rhosts
    • localhost guest
  • create a symbolic link to /.rhosts by  "ln -s /.rhosts /var/tmp/dead.letter"
  • run  "/usr/lib/sendmail unknown-user < fake",  which will create /.rhosts containing the line
    • localhost guest
  • Some useful find commands
  • find all the files owned by root and set-user-id bit set
    • find / -user root -perm -4000 -exec ls -l {} \; | mail root
  • find all the world-writable files
    • find / -perm -0002 -exec ls -l {} \; | mail root
  • find all the files named .rhosts
    • find /user -name .rhosts -exec ls -l {} \; | mail root
     
    11.3 sticky bits
    The sticky bit (file mode bit 01000)  is  used to  indicate  special  treatment of certain files and directories. 

    A file in a sticky directory may only be removed or renamed by a user who has write permission on the directory.  This is useful for directories such as /tmp, which must be publicly writable, but should deny users permission to arbitrarily delete or rename the files of others.

    If the sticky bit is set on a regular file and no execute bits are set, the system's page cache will not be used to hold the file's data.  This bit  is  normally set on swap files of diskless clients so that accesses to these files do not flush more valuable data from the system's cache.
     

  • Example of related exploits
  • /tmp is supposed be set with the sticky bit.  When it isn't, it can be exploited.

  • The command ps creates ps.xxxxx (xxxxx is the process-id of ps) and changes its ownership to root, and then renames the file as ps_data.

  • Attack is as follows:
  • prepare a personal sh file with set-user-id bit set
  • run ps
  • after ps.xxxxx  is created but before its ownership is changed, do the following very quickly:
  • delete /tmp/ps.xxxxx
  • ln -s personal-sh-file /tmp/ps.xxxxx
  • caveat: this attack cannot be done manually; we need to write a program to the above job.


    • 11.4 Buffer overflow
     

    Consider:
    char    s[10], t[100];
    ...
gets (s);
strcpy (s, t);
...
    A program like above may crash or show an unexpected behavior if the input to "gets(s)" or the string in "t[]" is larger than 10 bytes. If the program were running with root permission, its user may obtain a rootshell after the crash. A safe practice would have been to use "fgets()" and "strncpy()".
     
  • some buggy rlogin, rdist, lpr give away rootshell on buffer overflow
    • 11.5 TCP/IP Protocol Vulnerabilities
  • 3-way handshake protocol for establishing a TCP connection:
  • ICMP attacks
  • IP Spoofing


    • 11.6 Problematic programs
     

    11.7 Security Tools