link(2)
SunOS 4.1.*
The synopsis of the link(2) system call is:
int link(path1, path2)
char *path1, *path2;
Under SunOS 4.1.*, link(2) will incorrectly follow symbolic links
for path2.
Programs using the link(2) system call where path2 is located in a
publically writable directory, can potentially be used to gain root
access (e.g. the advisory:-
[8lgm]-Advisory-15.UNIX.mail3.28-Nov-1994
is based on binmail using this vulnerability in link(2).)
An example exploit for the [8lgm]-Advisory-15.UNIX.mail3.28-Nov-1994 advisory is available from the 8lgm fileserver, as of now. To obtain this program, send mail to 8lgm-fileserver@8lgm.org, with a line in the body of the message containing:-
A secure
Consider a program, creating hard links in a publically writable
directory, as a privileged uid. The program has no way of creating
a hard link in a secure manner (ie attempting to write code to
provide a workaround would be non-atomic, and therefore open to race
conditions. To use hard links in the situation described would
require using the
The
Sample locking code using
CA-95:02.binmail.vulnerabilities
The code contained in this advisory is a replacement for binmail,
and is recommended for use.
Contact vendor for fix.
8lgm@8lgm.org (Everything else)
All [8LGM] advisories may be obtained via the [8LGM] fileserver.
For details, '
DISCUSSION:
link(2) system call can allow path1 to be a symbolic link.
However, allowing path2 to be a symbolic link can potentially cause
security problems.
chroot(2) system call, producing a non-elegant
fix).
WORKAROUND:
link(2) system call is used almost exclusively for file locking.
Using the open(2) system call, it is possible to write a secure,
file locking mechanism.
open(2), and not link(2), can be seen in
CERT Advisory
FIX:
FEEDBACK AND CONTACT INFORMATION:
majordomo@8lgm.org (Mailing list requests - try 'help'
for details)
8LGM FILESERVER:
echo help | mail 8lgm-fileserver@8lgm.org'