oss-sec mailing list archives
The risks of cleaning /tmp
From: Dan Rosenberg <dan.j.rosenberg () gmail com>
Date: Thu, 17 Mar 2011 13:56:45 -0400
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
Current thread:
- The risks of cleaning /tmp Dan Rosenberg (Mar 17)
- Re: The risks of cleaning /tmp Nelson Elhage (Mar 17)