https://sourceware.org/bugzilla/show_bug.cgi?id=26945
Nick Clifton <nickc at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nickc at redhat dot com
Last reconfirmed| |2020-11-26
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Nick Clifton <nickc at redhat dot com> ---
Hi Rich,
> At least objcopy and perhaps other utilities generate a temp file safely
> with mkstemp then rename it to atomically replace the original, but the
> smart_rename function (binutils/rename.c) used to do this then performs
> chown and chmod on the target pathname rather than fchown/fchmod on the
> file. This is subject to all the classic symlink race attacks and can be
> used to get root to chown or chmod arbitrary files. In a worst case, with
> multiple racing file replacements, it can be used to chmod arbitrary
> root-owned files suid.
Not being a security expert, please can I check a couple of things with you:
The code in smart_rename() has already checked that the destination file
is not a symbolic link, so presumably the vulnerability occurs if the attacker
is able to replace the destination file after the rename has happened but
before the chmod() and/or chown() happen, right ?
So in order to protect the destination file it needs to be opened first and
then fchown/fchmod can be used. Bit isn't there still a period of
vulnerability between the call to rename() and the call to fopen() ? Or is
there a way to
rename a file and open it at the same time ?
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
