From: "David E. O'Brien" 
Subject: Re: Vulnerabilities minutes, 5 Nov 1997

> ---- ATTACKS #3 ----
> FUNDAMENTAL VULNERABILITIES: Inconsistency when a symbolic link is
> used: the SUID program checks the ownership of the symbolic link but
> not the target of the symbolic link.

Actually nm /usr/dt/bin/sdtcm_convert shows only stat(2) and fstat(2) are
called.  lstat(2) isn't used.  Thus the authors never even considered
symlinks.


As a side note, we need to be more exact as to the type of system (OS and
version) on this one.  Different systems have different symlink
symantics.  For instance:


    BSD
    ---
    -r--r--r--  1 root    wheel  3425 Nov  6 04:27 root-owned
    lrwxrwxrwx  1 root    wheel    10 Nov  6 04:28 root-sym@ -> root-owned
    lrwxrwxrwx  1 obrien  wheel    10 Nov  6 04:27 sym@ -> root-owned

    HP-UX
    -----
    -r--r--r--  1 root    root    337 Jun  10  1996 root-owned
    lrwxr-xr-x  1 root    users    10 Nov   6 04:31 root-sym@ -> root-owned
    lrwx------  1 obrien  users    10 Nov   6 04:31 sym@ -> root-owned


Notice that on BSD the symlink's permissions are 777, meaning the access
permissions are taken from the target of the link.  On HP-UX the
symlink's perms are a function of the umask setting (plus adding ``a+x''
for some reason).


The system call to get symlink information is lstat(2).  Note this from
the BSD manpage:

     Lstat() is like stat() except in the case where the named file is a
     symbolic link, in which case lstat() returns information about the
     link, while stat() returns information about the file the link
     references.  Unlike other filesystem objects, symbolic links do
     not have an owner, group, access mode, times, etc.  Instead, these
     attributes are taken from the directory that contains the link.  The
     only attributes returned from an lstat() that refer to the symbolic
     link itself are the file type (S_IFLNK), size, blocks, and link
     count (always 1).

I don't understand why they say symlinks don't have an owner.  lstat(2)
seems to provide useful and accurate information for most of the members
of ``struct stat''.


The HP-UX lstat(2) manpage is less clear about ownership.  Also note what
seems to be a contradiction about file modes:

      For symbolic links, the st_mode member will contain meaningful
      information when used with the file type macros, and the st_size
      member will contain the length of the pathname contained in the
      symbolic link. File mode bits and the contents of the remaining
      members of the stat structure are unspecified. The value returned
      in the st_size member is the length of the contents of the symbolic
      link, and does not count any trailing null.

-- 
-- David    (obrien@NUXI.ucdavis.edu)