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

[bugdal at aerifal dot cx]

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

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
It's not that smart_rename should open it and use fchown+fchmod on the result;
indeed as you figured that has the same race. The problem is that you threw
away the only safe way to perform modifications on the temp file you just
created: the fd returned by mkstemp. In addition to the source and dest names,
smart_rename needs to take the already-open file descriptors for source and
dest that were used for the objcopy (or whatever) operation.

Note: I missed this in the original report, but it's also important to use
fstat on the file that will be replaced, rather than lstat on the pathname, to
ensure the permissions that will be set on the new file are the ones of the
file that was processed, and not some other file that was substituted in its
place. Failure to do this right may not be exploitable, since the hard link
count is checked, but it's still possibly erroneous.

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