<<< Date Index >>>     <<< Thread Index >>>

Re: security problem with temp files [was Re: mutt_adv_mktemp() ?]



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