GNU bug report logs - #17103
cp: "cp -al" doesn't copy symlinks, tries to link to them

Previous Next

Package: coreutils;

Reported by: Linda Walsh <coreutils <at> tlinx.org>

Date: Wed, 26 Mar 2014 18:09:01 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Kees Cook <keescook <at> google.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 17103 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigbrady.com>
Subject: bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail)
Date: Fri, 28 Mar 2014 11:12:41 -0700
On Thu, Mar 27, 2014 at 7:25 PM, Linda Walsh <coreutils <at> tlinx.org> wrote:
> Kees Cook wrote:
>> Yeah, it'd be nice if the symlink bits had meaning. However, relaxing
>> this check on the kernel side results in bad scenarios, especially
>> when combined with the symlink restrictions. e.g., creating a hardlink
>> to a symlink that matches the directory owner in /tmp. Now an attacker
>> controls the destination of a followable symlink.
>
> ---
> Huh?   A symlink doesn't act like an SUID  (or has that
> changed?)  -- if the object the symlink pointed to was write protected
> against the user, they would still be hard pressed to exploit it.
>
> How would having a pointer to the file (that still follows tree
> traversal rules - i.e - only allowing access to paths the user could
> gotten to anyway) confer new access rights to a user?

It's not the access rights, but usually a ToCToU and/or race condition
problem in /tmp with symlinks. An outstandingly large amount of
administrative software is written that dumps things into /tmp with
static names. An attack can take advantage of that by dropping a
symlink in place in /tmp and the software follows it and does things
like overwrites /etc/passwd. So, the symlink restriction logic
basically says "owner of symlink must match dir owner or uid of
follower".

So, allowing a hardlink to a symlink means that symlinks owned by the
target user could be hardlinked to in /tmp. The attack gets more and
more remote, but these kind of flaws are not unheard of.

Regardless, if your system isn't at risk for such attacks, makes sense
to turn if off if it's getting in your way. :)

-Kees

-- 
Kees Cook
Chrome OS Security




This bug report was last modified 6 years and 157 days ago.

Previous Next


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