[Bug binutils/26945] Unsafe chown+chmod in smart_rename, possibly elsewhere

[nickc at redhat dot com]

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.