Security problems with mktemp race condition. From Linux Security FAQ Update #10 There is a good bit of stuff done between the mktemp() and the actual usage of the temporary file, so this bug is not very difficult to exploit. This bug could allow another local user to execute commands as you, when you start FVWM. Fix: This should take care of it. This is a slightly cleaned up version of the fix by Debian/GNU Linux.
>>Description: >Security problems with mktemp race condition. >From Linux Security FAQ Update #10 >There is a good bit of stuff done between the mktemp() and the actual usage of >the temporary file, so this bug is not very difficult to exploit. This bug >could allow another local user to execute commands as you, when you start FVWM. BSD provides mkstemp() to handle this problem properly. I'm not sure of it's history, but it is old enough to be in FreeBSD-1.1.5. I tried exploiting the bug in mktemp() pointed out by Josh the other day (mk[s]temp() uses stat(), not lstat(), so mktemp() can return a filename that is a symlink. This doesn't seem to be a problem for mkstemp() since O_EXCL in the open flags stop all (?) existing directory entries from being openable). >+ /* make a directory to guard against following symlinks */ >+ if (mkdir(tmp_name, 0700) != 0) { >+ perror("exclusive open for tmp_name failed in m4_defs"); >+ exit(0377); >+ } >+ strcat(tmp_name, "/data"); /* what actual tmp file is to be called */ I think the O_EXCL method is better. Except of course if you really want a directory or another type of non-regular file. It's surprisingly hard to get the interface for temporary file [name] creation right. FreeBSD has 5 BAD interfaces: tempnam(), tmpfile(), tmpnam(), mktemp() and mkstemp(). Bruce
Responsible Changed From-To: freebsd-bugs->pst
State Changed From-To: open->closed Fix submitted to author.