bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#35654: We've found a vulnerability of gnu chown, please check it and


From: Bob Proulx
Subject: bug#35654: We've found a vulnerability of gnu chown, please check it and request a cve id for us.
Date: Tue, 14 May 2019 01:53:28 -0600
User-agent: Mutt/1.10.1 (2018-07-13)

The essence of this report appears to be an attack of the form, can we
get the root user to perform an unsafe operation, in this case can we
trick root into dereferencing a symbolic link, such as from ./poc to
/etc, in order to perform a further action through the symlink.

However this is not a bug in chown's -h implementation.  Nor is it
particular to chown as this could be any other command as the trick to
dereference the symlink first before performing whatever action.  For
example here is a recipe using the same attack but without chown.

  ln -s /etc /tmp/junk
  # Now we trick root into reaching through the symlink.
  # No way root will see this trick coming!
  rm -f /tmp/junk/*
  # This removes the files from /etc.

The above does not use chown -h but is essentially the same attack.
However again this is not a bug in 'rm' nor 'ln'.  It is simply trying
to trick the superuser into doing unsafe actions.  It requires
cooperation on the part of root in order to perform the action.

But why would the superuser do such silly things?  This is very much
like Coyote painting a black image on the side of the mountain hoping
the Road Runner will mistake it for a tunnel and run into the mountain
becoming dinner for Coyote.  But the Road Runner never fell for such
tricks and neither should the superuser.  That it might happen does
not make black paint a threat to the Road Runner.

The use of 'sudo' does not change the nature of the issue.  Only the
root user can install sudo and configure it to perform the unsafe
actions as you have described.  And it also requires a local user to
look the superuser in the eye and try to con them up close and
personal.

Note that this is essentially the same in legacy Unix and in *BSD
where symbolic links originated.  The community has had decades to
poke at them.  It is even more interesting to poke at systems that
allow environment variables in symbolic links in which case the target
is dependent upon the runtime environment variables!

The root user is the superuser and with great power comes great
responsibility.  Extraordinary claims require extraordinary proof.  In
order for symlinks to be considered as a security vulnerability a more
convincing case will need to be presented.

Bob





reply via email to

[Prev in Thread] Current Thread [Next in Thread]