[20444] in bugtraq
Re: Linux patches to solve /tmp race problem
daemon@ATHENA.MIT.EDU (Donaldson, Matthew)
Thu Apr 26 01:10:20 2001
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15078.61650.196935.160361@localhost.localdomain>
Date: Thu, 26 Apr 2001 01:14:18 +0930
Reply-To: matthew@DATADELIVERANCE.COM
From: "Donaldson, Matthew" <matthew@DATADELIVERANCE.COM>
X-To: Valdis.Kletnieks@vt.edu
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <200104251405.f3PE5wN09408@foo-bar-baz.cc.vt.edu>
Valdis.Kletnieks@vt.edu writes:
>On Tue, 24 Apr 2001 20:13:30 +0930, "Donaldson, Matthew" <matthew@DATADELIVERANCE.COM> said:
>> (e.g. because it's non open-source). Having something like this gives them
>> the security that even if someone is doing the Wrong Thing(tm), it does not
>> put them at risk.
>
>Puts them at much less risk. The risk is still non-zero. (Consider - does
>the patch fix race conditions that happen to involve both /tmp *and* '..'
>in the pathname? What *other* end conditions are there? Remember that
>"non executable stack" patches don't stop all buffer overflows, they just
>make them a LOT harder to exploit.....
I see your point about buffer overflows, but I'm not sure that the same
applies to /tmp races: maybe I'm missing something, but my perception of the
the essence of /tmp races is this: someone sticks a symlink in /tmp just
before a privileged user (e.g. root) is about to create a file with that
name. Privileged user doesn't check properly, and writes stuff to the
file the non-privileged user selected.
If each user has a separate /tmp directory, unwritable by anyone else, this
is no longer possible, so far as I can see. Now maybe I'm overlooking things
here - I'd be most interested to hear of types of /tmp races not solved by
this proposal, and how using '..' in the path name might make things trickier.
Now of course the price you pay is that if things are designed to cooperate
using files in /tmp, and they run as different users, you have to make them
agree on somewhere else to put files, or use a different communication
mechanism. More on that in my reply to Chris Wright (tomorrow - it's getting
late here), who raised that issue. X is a particularly bad offender in this
category, but there are some fairly simple workarounds.
Cheers
-Matthew
--
+--------------------------------------------------------------------------+
| Matthew Donaldson http://www.datadeliverance.com |
| Data Deliverance Pty. Ltd. Email: matthew@datadeliverance.com |
| 30 Musgrave Ave. Phone: +61 8 8265 7976 _ |
| Banksia Park Fax: +61 8 8265 0032 John / \/ |
| South Australia 5091 3:16 \_/\ |
+--------------------------------------------------------------------------+
