Re: The risks of cleaning /tmp

[Nelson Elhage <nelhage () ksplice com>]

The tmpreaper package (at least in Debian) has a pretty good writeup
of a lot of the security problems involved in cleaning /tmp, which
I've copied at <http://nelhage.com/files/README.security>, since I
can't find another good source online.

It's probably worth reading that document to get perspective on some
of the thought that's been put into this problem before.

- Nelson

On Thu, Mar 17, 2011 at 1:56 PM, Dan Rosenberg
<dan.j.rosenberg () gmail com> wrote:
> 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