[ Search ] [ What's New? ] [ About ]
[ Bugs ] [ Misc ] [ Mailing Lists ] [ Newgroups ] [ NewsWire ] [ Papers ] [ People ]
[ Pictures ] [ Publications ] [ Responce Teams ] [ Tools ] [ Upcoming Events ] [ Web Sites ]

expreserve(1)
Systems Affected: This bug exists in all expreserves up to BSD 4.3. (well not quite). On all System V and earlier releases this works. Under System V expreserve places the Ex temp files in the directory /usr/preserve/$LOGNAME and under Berkeley releses it places them under either /usr/preserve or /var/preserve (SunOS 4.X among others).
Problem: A rather barbaric race condition in expreserve that allows the setuid program to be compromised by changing the permissions of a file. This "feature" will allow security to be breached on all standard Systems Vs and all Berkeley-ish systems that have the /usr/preserve directory writable by the user (Note: SunOS was this directory unwritable by default). The System V bug was relatively unavoidable (though the addition of the "S" bit to directories in SVR3.2 could close the hole) until SVR4 but the Berkeley bug should have been fixed as soon as the fchown(2) system call was added to BSD. Basically the "hole" is that expreserve does: 

	fd = creat("/usr/preserve/Exaaa$PID", 0600);
	chown("/usr/preserve/Exaaa$PID", real_uid, real_gid);

when it should do a: 

	fd = creat("/usr/preserve/Exaaa$PID", 0600);
	fchown(fd, real_uid, real_gid);

which avoids the race (it changes the permission on the inode that was creat(2)ed and not the inode whose name is /usr/preserve/Exaaa$PID). The previous examples are actually simplified as expreserve actually looks at the uid and gid as stored in the /tmp/Ex$PID file and compares them to the getuid() and getgid() return values. The actual race is that a context switch may occur between the creat(2) and chown(2) in expreserve that allows another process with write permission to the target directory to unlink(2) the creat(2)ed file and place a hard link to another file by that name in the target directory, which expreserve subsequentialies chown(2)s to your uid. This "feature" allows any file on the same device to be chown(2)ed to you. Though you may see support for symbolic links, on the version of UNIX that I have tested this on, this will only change permissions on the symlink. I find this confusing as ELOOP is an alleged failure condition for chown(2) implying that a symbolic link resolution.

Solution:

Aleph One / aleph1@underground.org
Copyright © 1996 Computer Underground Society. All rights reserved.