bug-binutils
[Top][All Lists]
Advanced

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

[Bug binutils/26945] New: Unsafe chown+chmod in smart_rename, possibly e


From: bugdal at aerifal dot cx
Subject: [Bug binutils/26945] New: Unsafe chown+chmod in smart_rename, possibly elsewhere
Date: Wed, 25 Nov 2020 16:01:05 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=26945

            Bug ID: 26945
           Summary: Unsafe chown+chmod in smart_rename, possibly elsewhere
           Product: binutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

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.

This is only an issue if the file being operated on is in a directory writable
by the attacker. However, the whole point of the ownership/permissions
restoration logic seems to be for the case where root is operating on other
users' files, and it seems likely that the directory will also be user-owned.

I'm reporting this through public issue rather than security because I don't
think there are direct ways to exploit it programmatically in a normal
environment. There may be when the affected tools are used in automated scripts
acting on user-owned files, though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

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