[UNIX] GNU rm fileutils Race Condition Problems on SuSE

From: support@securiteam.com
Date: 05/18/02 

From: support@securiteam.com
To: list@securiteam.com
Date: Sat, 18 May 2002 22:52:17 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  GNU rm fileutils Race Condition Problems on SuSE
------------------------------------------------------------------------

SUMMARY

A security vulnerability arises from the fact that there is a race
condition while recursively-removing directory structures from
world-writeable directories. This vulnerability causes the rm(1) command
to be vulnerable to an attack that allows a local user to remove arbitrary
directories (and files) from the system.

DETAILS

Vulnerable systems:
SuSE Linux version 7.3 and prior

Problem description:
There is an exploitable call to the vulnerable rm -rf command in
/etc/cron.daily/aaa_base_clean_core as follows:

#
# paranoia settings
#
umask 022

PATH=/sbin:/bin:/usr/sbin:/usr/bin
export PATH
TMPDIR=/var/tmp/cron.daily.$$
rm -rf $TMPDIR

This script is run every day as ROOT even if the user did not set the
DELETE_OLD_CORE variable in /etc/rc.config.

Technical details:
As pointed out by <mailto:mailto:cliph@isec.pl> Wojciech Purczynski there
is a race condition in the GNU 'rm' utility while removing directories
recursively. In particular it is possible to create a deeply nested
directory structure in /tmp, wait for removal of one of the leafs and
quickly move the directory root 2 levels up. This will force rm to
chdir("..") two levels more than intended, resulting in the removal of the
complete file system.

An exploit code will not be released, but exploitation is very
straightforward, since the race window can be made mostly as big as needed
(it is even possible to exploit this vulnerability 'by hand'). One needs
to create a directory structure like this:

/tmp/cron.daily.PID/root/1/2/3/4/5/6/7/8/......./N
                        /(N+1)/(N+2)/.........../2*N
                        .........................

And wait for the removal of the 'N' leaf. This can be easily accomplished
since the clean_core script is called at a very well defined time (between
0:15:00 and about 0:15:15 every day) - so we can create X of those nested
directories, wait until 15:00, get the next PID and begin to move those
directories to match the next X PIDs. Guessing the next PID can be done by
reading /proc/stat and evaluating the 'processes' entry (or less elegant
by continuous forking.

ADDITIONAL INFORMATION

The information has been provided by <mailto:paul@starzetz.de> Paul
Starzetz.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages