Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Takahiro Kambe (tacasky.yamashina.kyoto.jp)
Date: Mon Mar 11 2002 - 16:13:47 CST
Is this problem applicable to our rm(1)?
-- Takahiro Kambe <tacasky.yamashina.kyoto.jp>
attached mail follows:
-----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 <cliphisec.pl> Date: March 10, 2002
Race condition in various utilities from fileutils GNU package may cause root user to delete the whole filesystem.
The GNU File Utilities are the basic file-manipulation utilities of the GNU operating system.
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.
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.
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:
iD8DBQE8i+qNC+8U3Z5wpu4RAghyAJ9GGyLa/su8zTYhTo4nM0pIKQWaoQCfcHpL ou2hoatHjGW+V05SB2LrS9g= =kD85 -----END PGP SIGNATURE-----