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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18280 in the body.
You can then email your comments to 18280 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

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

Message #8 received at 18280 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Tobias Stoeckmann <tobias <at> stoeckmann.org>, 18280 <at> debbugs.gnu.org
Subject: Re: bug#18280: chmod: race condition
Date: Sat, 16 Aug 2014 13:53:07 -0700

Tobias Stoeckmann wrote:
> But I will recommend to look into
> the use of fchmodat() instead, supplying the argument
> AT_SYMLINK_NOFOLLOW.

Sorry, that won't work, and this is a known bug.  Please see:

http://bugs.gnu.org/11108

Message #13 received at 18280 <at> debbugs.gnu.org (full text, mbox):

From: Tobias Stoeckmann <tobias <at> stoeckmann.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 18280 <at> debbugs.gnu.org
Subject: Re: bug#18280: chmod: race condition
Date: Sun, 17 Aug 2014 13:46:13 +0200

On Sat, Aug 16, 2014 at 01:53:07PM -0700, Paul Eggert wrote:
> Tobias Stoeckmann wrote:
> >But I will recommend to look into
> >the use of fchmodat() instead, supplying the argument
> >AT_SYMLINK_NOFOLLOW.
> 
> Sorry, that won't work, and this is a known bug.  Please see:
> 
> http://bugs.gnu.org/11108

I investigated into this and installed the mentioned Fedora 17
distribution on a virtual machine.  The bug report is correct, chmod
fails to adjust the permission of files and directories with fchmodat
and AT_SYMLINK_NOFOLLOW in place.

Opening the manual page helped me though:

$ man fchmodat
[...]
AT_SYMLINK_NOFOLLOW
    If pathname is a symbolic link, do not dereference it: instead operate
    on the link itself. This flag is not currently implemented.
[...]
ENOTSUP
    flags specified AT_SYMLINK_NOFOLLOW, which is not supported.


So in short, Fedora 17 and even later versions simply don't support the
flag.  I'm not convinced that due to the lack of implementation of some
systems, everyone should suffer.

For me, it sounds like configure should run a functionality test, calling
fchmodat with AT_SYMLINK_NOFOLLOW and see if it fails and ENOTSUP is set
in errno.  In that case, don't call fchmodat or force 0 for flags,
otherwise use AT_SYMLINK_NOFOLLOW.


Tobias

Message #16 received at 18280 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Tobias Stoeckmann <tobias <at> stoeckmann.org>
Cc: 18280 <at> debbugs.gnu.org
Subject: Re: bug#18280: chmod: race condition
Date: Sun, 17 Aug 2014 07:45:48 -0700

Tobias Stoeckmann wrote:
> For me, it sounds like configure should run a functionality test, calling
> fchmodat with AT_SYMLINK_NOFOLLOW and see if it fails and ENOTSUP is set
> in errno.  In that case, don't call fchmodat or force 0 for flags,
> otherwise use AT_SYMLINK_NOFOLLOW.

Yes, that sounds like a reasonable way to move forward.  At least, that 
is what I was thinking of doing in 2012.  I never got around to it, 
partly because (although it's an improvement) it's not a complete fix 
for the race.

Previous Next

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