On Wed, Oct 04, 2006 at 10:58:40PM +0200, Thomas Roessler wrote: > On 2006-10-04 16:39:29 -0400, Derek Martin wrote: > > > It would seem that Mutt's temp file creation mechanisms all > > suffer from a potentially exploitable race condition. Actually > > there are two: one in functions that call safe_open(), which only > > affects users creating temp files on NFS file systems (due to the > > O_EXCL problem), and one in functions that make use of > > safe_fopen(), because the resulting file is not adequately > > checked to determine if other users can modify it before it is > > written to. > > Well, umask (077) is one of the first things mutt does, so the > second problem looks like a non-issue to me. (I.e., other users > can't modify the temporary file unless the owner deliberately > changed the permissions. Oh well.) Not so. An attacker could create the file first, in between the call to mktemp() and fopen(). As I said in my last message, the call to fopen(blah, "w+") will truncate the file if it exists, but it does nothing to ensure the modes of any existing file, nor will your umask. This is easy to demonstrate, using the attached program. The timing to do this is excruciating; but exploits to do exactly this kind of thing have been published to bugtraq and vuln-dev before. Whereas the file names being fed to safe_fopen() are extremely guessable, this is a real problem. Demo: $ gcc -o fopen fopen.c $ whoami foo $ ls -l /tmp/mutt-host-uid-pid-counter ls: /tmp/mutt-host-uid-pid-counter: No such file or directory $ ./fopen /tmp/mutt-host-uid-pid-counter At this point, the program will sleep for 30 seconds to give you the chance to pretend you're a fast CPU. ;-) Now, as a different user, run the following commands in a different window: $ sudo su bar Password: $ touch /tmp/mutt-host-uid-pid-counter $ chmod 666 /tmp/mutt-host-uid-pid-counter $ ls -l /tmp/mutt-host-uid-pid-counter -rw-rw-rw- 1 bar bar 0 Oct 4 17:52 /tmp/mutt-host-uid-pid-counter Now wait for the program to finish. Once it does, check on your file: $ ls -l /tmp/mutt-host-uid-pid-counter -rw-rw-rw- 1 bar bar 5 Oct 4 17:52 /tmp/mutt-host-uid-pid-counter Oops, that's not what we want! But did the program finish? $ cat /tmp/mutt-host-uid-pid-counter test Yup. The stuff we expected is in the file; it just has the wrong permissions and ownership. This is bad, because bar can now replace the contents with whatever he wants. If his exploit is well-written, he may be able to do this before mutt is able to fork/exec the helper program. And actually, since fork and exec are both kind of expensive, this is actually somewhat likely. I few microseconds would be enough to replace the existing content with, say, a web page that automatically downloads a java applet to delete all the files on your system (or whatever, use your imagination). > I'll admit that my memory of NFS subtleties is getting rusty at this > point. Mind to elaborate on what safe_open ought to do besides the > check of comparing fstat and lstat results? The scheme I outlined in the previous message of creating a temporary directory with permissions 700 and creating temp files in there, checking permissions before trusting temp files, is suitable to fix both problems. Best of all, using that solution makes temp file creation consistent for all uses of temp files, which currently is not the case. I'll note that mutt should be careful to remove any such temp directory upon exit or receiving a signal which would normally terminate it. Anywhere mutt needs to do this for files which are intended to hang around, e.g. new mbox folders, you can do that and then link(2) it to the temp file. Should existing mutt users run in fear from using mutt while these problems exist? No... and careful users who set TMPDIR to be some directory which no one but their own programs has any business being in will make this problem go away. [Thatt even fixes the NFS race condition (not fixed, but rendered harmless), unless the user somehow manages to run two copies of mutt on the same host which have the same PID.*] HOWEVER, I think it still needs to get fixed. While users of POSIX systems were once savvy geeks who always read manuals, that's no longer the case. I'd venture a guess that a lot of people reading this list don't even know about TMPDIR, let alone the mutt-specific setting for it. We can't count on users to know what they're doing. [*] This is not as unlikely as it seems, especially in an age where everyone has root/Admin access to their laptops. It doesn't matter what the DNS name of the host is... it only matters what hostname the machine thinks it has. No guarantee of uniqueness there, especially if someone's doing something funny. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers.
Attachment:
pgpFYEgadsIN2.pgp
Description: PGP signature