Bug#174987: tetex-bin: xdvi wrapper has a temporary file race condition (security hole)

[Julian Gilbey <jdg@polya.uklinux.net>]

severity 174987 grave
thanks

Atsuhito,

Ken's right; this is a bad bug. :-(  Mea culpa.
Please can you do an upload with the new as soon as is possible?
(It's not in testing yet, so no need to do more than upload.)

Thanks,

   Julian

----- Forwarded message from Ken Shan <ken@digitas.harvard.edu> -----

Date: Thu, 2 Jan 2003 18:50:52 -0500
From: Ken Shan <ken@digitas.harvard.edu>
Subject: Re: Bug#174987: tetex-bin: xdvi wrapper has a temporary file race condition (security hole)
To: Julian Gilbey <jdg@polya.uklinux.net>

Hello Julian,

I tried to read the File::Temp documentation in detail, but it's still
not clear to me that the way the current xdvi wrapper creates and uses
temporary files is secure.  Could you please help me understand?

The usual race condition problem with temporary file creation is that
the test for the nonexistence of a file does not immediately precede the
creation of that file.  That is the problem dealt with by File::Temp
and not what I am worried about.  What I am worried about is that the
creation of the temporary file does not immediately precede the use of
the file by gzip/bzip2 and xdvi.bin.

Here is a simple test that illustrates my concern; you can try it out on
your system.  First, create a world-writable directory and change to it.
Then, run the following Perl program:

    use File::Temp qw(tempfile);
    ($fh, $filename) = tempfile("testXXXXXX", SUFFIX => ".dvi");
    print "$filename\n";
    scalar(<>);
    open TEMP, ">", $filename;
    print "Done\n";

The program will create a temporary file, print its name, and wait for a
carriage return.  Without hitting carriage return, open another window
and switch to an unprivileged user like nobody.  As nobody, you should
be able to replace the temporary file by a symbolic link pointing at a
file owned by (and only writable by) your non-nobody account.  If you
do so, then hit carriage return in the first window, you will overwrite
the file pointed to.

To relate this experiment to xdvi, suppose that Alice changes into a
world-writable directory, then invokes xdvi to view a compressed file
that resides in another (non-world-writable) directory.  Mallory, who has
local access, can cause Alice to write decompressed dvi data to any file
she can write to, or to invoke xdvi.bin on any file she can read from.
I think this is why the File::Temp documentation warns people that "If
you need to pass the handle to something that expects a filename then,
on a unix system, use ""/dev/fd/" . fileno($fh)" for arbitrary programs".
Perhaps I missed something?

----- End forwarded message -----

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

        Julian Gilbey, website: http://www.polya.uklinux.net/
   Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
     Visit http://www.thehungersite.com/ to help feed the hungry