5255081 2000-07-05  21:55  /38 rader/ Postmaster
Mottagare: Bugtraq (import) <11573>
Ärende: XFree86 4.0.1 and /tmp
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
X-Sender: jsm28@red.csi.cam.ac.uk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.SOL.4.21.0007022135140.22926-100000@red.csi.cam.ac.uk>
Date:         Sun, 2 Jul 2000 22:00:04 +0100
Reply-To: "Joseph S. Myers" <jsm28@CAM.AC.UK>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: "Joseph S. Myers" <jsm28@CAM.AC.UK>
To: BUGTRAQ@SECURITYFOCUS.COM

When XFree86 4.0.1 is installed from source on Linux, it creates
".so" man page aliases as temporary files in /tmp, which then get
installed under /usr/X11R6/man.  (Imake.rules,
InstallManPageAliases.)  The temporary filename is determined from
the process id; it is removed before being overwritten, but shell
redirection without noclobber is used and the process id is
predictable so the race should not be difficult to win.  The install
from source would normally run as root.  TMPDIR is not honoured.

This problem has been in XFree86 for a long time.  There are several
other /tmp problems in XFree86: gccmakedep (shell script) uses /tmp
insecurely, although on the 3.3.x branch it uses mktemp(1); imake, on
Linux only, uses tmpnam(3) insecurely when determining the libc
version (and, in 4.0, imake had a regression from 3.3.x with insecure
use of mktemp(3); this has been fixed in 4.0.1); xman uses mktemp(3)
insecurely; both versions of libXaw use tmpnam(3) and show no signs
of using O_EXCL (but I'm not sure under what circumstances Xaw
actually uses temporary files).  It doesn't seem any of these will
follow TMPDIR either.

All these problems were reported to XFree86 in March after the
release of XFree86 4.0.

--
Joseph S. Myers
jsm28@cam.ac.uk
(5255081) ------------------------------------------(Ombruten)