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 . 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  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.