bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail)

[Kees Cook]

On Thu, Mar 27, 2014 at 7:25 PM, Linda Walsh <address@hidden> 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