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)