GNU bug report logs - #11108
chmod: fix symlink race condition

Previous Next

Package: coreutils;

Reported by: Paul Eggert <eggert <at> cs.ucla.edu>

Date: Wed, 28 Mar 2012 06:01:01 UTC

Severity: wishlist

Tags: patch

Merged with 18280, 32772

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Tobias Stoeckmann <tobias <at> stoeckmann.org>
Subject: bug#18280: closed (Re: bug#11108: [PATCH] chmod: fix symlink race
 condition)
Date: Wed, 20 Mar 2024 19:10:02 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#11108: chmod: fix symlink race condition

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 18280 <at> debbugs.gnu.org.

-- 
11108: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11108
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Pádraig Brady <P <at> draigBrady.com>
To: 11108-done <at> debbugs.gnu.org
Subject: Re: bug#11108: [PATCH] chmod: fix symlink race condition
Date: Wed, 20 Mar 2024 19:01:22 +0000
On 28/03/2012 21:28, Paul Eggert wrote:
> On 03/28/2012 01:13 PM, Jim Meyering wrote:
>>      $ ./chmod u+w f
>>      ./chmod: changing permissions of 'f': Operation not supported
> 
> Yeouch.  I undid the change for now.
> Hmm, why did "make check" work for me?
> I'll have to investigate later, alas.

Patch for this pushed at:
https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=v9.4-163-g425b8a2f5

Marking this as done.

cheers,
Pádraig.

[Message part 3 (message/rfc822, inline)]
From: Tobias Stoeckmann <tobias <at> stoeckmann.org>
To: bug-coreutils <at> gnu.org
Subject: chmod: race condition
Date: Sat, 16 Aug 2014 19:44:47 +0200
Hi,

chmod is vulnerable to a TOCTTOU (time of check to time of use) race
condition. Tested this on an OpenBSD system.  For people unfamiliar
with OpenBSD, /etc/master.passwd basically equals /etc/shadow:

# chmod --version | head -n 1
chmod (GNU coreutils) 8.23
# ls -l /etc/master.passwd
-rw-------  1 root  wheel  4244 Jul 23 21:14 /etc/master.passwd
# chmod -R g+w /usr/src
<second console interferes here>
# ls -l /etc/master.passwd
-rw-rw-r--  1 root  wheel  4244 Jul 23 21:14 /etc/master.passwd

$ rm /usr/src/Makefile
$ ln -s /etc/master.passwd /usr/src/Makefile

For the second console, the user belonged to the same group as
/usr/src (wsrc in this example).

The second console is able to modify Makefile because the directory
/usr/src was already made group-writable.

The race happens in src/chmod.c, around function process_file.  Before
it gets called, fts_read() retrieved information about the _file_
Makefile, i.e. before the second console removed it.

Then the file gets replaced by a symlink, pointing to a file we want
to get modified.  Now chmodat() resolves the path again and actually
evaluates the _symlink_.  The destination file /etc/master.passwd can
be happily parsed by the attacker now.


I won't supply a patch now, as I remember that GNU is a bit picky about
accepting patches from everyone.  But I will recommend to look into
the use of fchmodat() instead, supplying the argument
AT_SYMLINK_NOFOLLOW.  We discuss this solution at OpenBSD currently.


Tobias



This bug report was last modified 1 year and 118 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.