[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikK2KVBKenHmgm8j27=aNmrPVhyQUfH=tz3PUB3@mail.gmail.com>
Date: Thu, 17 Mar 2011 13:56:45 -0400
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: oss-security@...ts.openwall.com
Subject: The risks of cleaning /tmp
Hi all,
A number of utilities (notably tmpwatch on Red Hat/Fedora) are
designed to regularly clean the contents of the /tmp directory. I
wanted to draw some attention to the fact that these applications, as
well as setting up cronjobs to perform the same task, introduce the
same risks as detailed in Tavis Ormandy's advisory for seunshare [1].
Namely, they make it such that the stickiness of /tmp can no longer be
relied on.
Consider a setuid application that relies on the fact that users can't
delete its resources in /tmp because they're root owned. An attacker
can simply launch the application and send a SIGSTOP at the right
moment to cause it to sleep indefinitely, until tmpwatch (or similar)
removes its /tmp resources, allowing them to be replaced by the
attacker. As Tavis pointed out, doing this with ksu could allow
denial of service, but it may be possible to escalate privileges by
leveraging other applications.
It seems like a difficult problem to solve - it's hardly feasible to
rewrite every suid app that relies on the stickiness of /tmp.
Hopefully we can generate some useful discussion here.
Regards,
Dan
[1] http://marc.info/?l=full-disclosure&m=129842239022495&w=2
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
