SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (Generic)  >   Fileutils (GNU) Vendors:   [Multiple Authors/Vendors]
GNU Fileutils Package Race Condition May Allow Local Users to Cause a Root User to Remove the Entire Filesystem
SecurityTracker Alert ID:  1003797
SecurityTracker URL:  http://securitytracker.com/id/1003797
CVE Reference:   CVE-2002-0435   (Links to External Site)
Updated:  Feb 9 2007
Original Entry Date:  Mar 12 2002
Impact:   Denial of service via local system, Modification of system information, Modification of user information
Fix Available:  Yes  Vendor Confirmed:  Yes  Exploit Included:  Yes  
Version(s): 4.1 stable and 4.1.6 development version
Description:   A race condition vulnerability was reported in the GNU Fileutils package. A local user may be able to cause the entire filesystem to be removed by a root level user when the root user attempts to remove another directory (under certain conditions).

It is reported that a race condition exists in several components of the GNU fileutils package that may allow a local user to cause the root user to delete the entire filesystem.

According to the report, an insecure chdir("..") syscall is performed after removing the content of a subdirectory in order to get back to the upper directory during recursive removal of directory tree.

Condsider the following example of 'rm -fr /tmp/a' removing '/tmp/a/b/c' directory tree:

(strace output simplified for better readability)

chdir("/tmp/a") = 0
chdir("b") = 0
chdir("c") = 0
chdir("..") = 0
rmdir("c") = 0
chdir("..") = 0
rmdir("b") = 0
fchdir(3) = 0
rmdir("/tmp/a") = 0

In the above example, the race condition occurs after the current directory is changed to /tmp/a/b/c. If a local user then moves the /tmp/a/b/c directory to the /tmp/c directory, the two subsequent chdir("..") syscalls will apparently change to the root directory / and then rm will start removing files from the entire file system (if the calling user has sufficient privileges).

Impact:   A local user may be able to cause the entire filesystem to be removed by a root level user when the root user attempts to remove another directory (under certain conditions).
Solution:   The vendor has released a patch for the latest 4.1.6 development version, available at:

http://mail.gnu.org/pipermail/bug-fileutils/2002-March/002440.html

Vendor URL:  www.gnu.org/software/fileutils/fileutils.html (Links to External Site)
Cause:   State error
Underlying OS:  Linux (Any), UNIX (Any)

Message History:   This archive entry has one or more follow-up message(s) listed below.
(Caldera Issues Fix for OpenLinux) Re: GNU Fileutils Package Race Condition May Allow Local Users to Cause a Root User to Remove the Entire Filesystem
The vendor has issued a fix.
(Caldera Issues Revised Fix for OpenLinux) GNU Fileutils Package Race Condition May Allow Local Users to Cause a Root User to Remove the Entire Filesystem
Caldera has released a revised fix to replace the previous fix.
(Mandrake Issues Fix) GNU Fileutils Package Race Condition May Allow Local Users to Cause a Root User to Remove the Entire Filesystem
The vendor has released a fix.
Feb 9 2007 (Sun Issues Fix) GNU Fileutils Package Race Condition May Allow Local Users to Cause a Root User to Remove the Entire Filesystem
Sun has issued a fix for Sun Solaris 8, 9, and 10.



 Source Message Contents

Subject:  GNU fileutils - recursive directory removal race condition


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Name:		fileutils
Version:	4.1 stable and 4.1.6 development version
Homepage:	http://www.gnu.org/software/fileutils/fileutils.html
Author:		Wojciech Purczynski <cliph@isec.pl>
Date:		March 10, 2002


Issue:
======

Race condition in various utilities from fileutils GNU package may cause
root user to delete the whole filesystem.


Description:
============

The GNU File Utilities are the basic file-manipulation utilities of the
GNU operating system.


Details:
========

An insecure chdir("..") syscall is done after removing content of a
subdirectory in order to get back to the upper directory during recursive
removal of directory tree.

Example of 'rm -fr /tmp/a' removing '/tmp/a/b/c' directory tree:

(strace output simplified for better readability)

chdir("/tmp/a")                         = 0
chdir("b")                              = 0
chdir("c")                              = 0
chdir("..")                             = 0
rmdir("c")                              = 0
chdir("..")                             = 0
rmdir("b")                              = 0
fchdir(3)                               = 0
rmdir("/tmp/a")                         = 0

After current directory is changed to /tmp/a/b/c a race condition occurs.
If we then move /tmp/a/b/c directory to the /tmp/c two subsequent
chdir("..") syscalls will move to the root directory / and rm will start
removing files from the whole file systems if it has enough privileges
(i.e. if called by root user).

Timeframe of this race condition depends on how complicated directory
structure is.

The same issue affects also mv utility when source and destination
directory lie on different filesystems and they are removed after
creating copy on destination.


Impact:
=======

Unprivileged users may launch daemon program that will detect the removal
operation of user's directories and exploit race condition leading to
Denial of Service.


Fix:
====

On March 7, 2002 we have contacted with developers of GNU fileutils
package. On March 9, 2002 a patch fixing this vulnerability has been
released for the latest 4.1.6 development version:

http://mail.gnu.org/pipermail/bug-fileutils/2002-March/002440.html


- -- 
Wojciech Purczynski
iSEC Security Research
http://isec.pl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8i+qNC+8U3Z5wpu4RAghyAJ9GGyLa/su8zTYhTo4nM0pIKQWaoQCfcHpL
ou2hoatHjGW+V05SB2LrS9g=
=kD85
-----END PGP SIGNATURE-----



 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, SecurityGlobal.net LLC