There is an open race window when writing output in the following utilities in GNU binutils version 2.35 and earlier:ar, objcopy, strip, ranlib.
When these utilities are run as a privileged user (presumably as part of a script updating binaries across different users), an unprivileged user can trick these utilities into getting ownership of arbitrary files through a symlink.
Created binutils tracking bugs for this issue:
Affects: fedora-all [bug 1913744]
Created mingw-binutils tracking bugs for this issue:
Affects: fedora-all [bug 1913745]
There's an issue with smart_rename() function from the binutils package. When called with a symlink as destination the function is exposed to a race condition which eventually allows an unprivileged attacker gain access to privileged files. Although the flaw existence the impact is reduced as several pre-conditions must be achieved to making the malicious able to reach such result, also the function is not exposed to any API, being used in specific utilities only.
Nick, can you advise me WRT testing of this patch? There seems to be no clear reproducer, and upstream patches don't update any test cases.
There's no reproducer for this as the preconditions make the bug fairly hard to exploit. I would suggest sanity testing only, i.e.:
1. Making sure that the testsuite runs clean
2. When run as root, ar, strip, objdump, objcopy, etc. should preserve permissions and ownership of existing files
3. When run as non-root too, those utilities should preserve permissions and ownership of existing files.
4. When run as non-root, ar should create files with correct permissions and also not crash.
Test (4) fails for the 3 patches in comment 9 due to the following upstream bugs (regressions from those patches):
There's a fourth patch under review to fix them:
Given Siddhesh's comments it looks like this BZ is not going to be easy to test. Sorry about that.
The only thing that I would add is that given that the theoretical attack involves tricking root into running a binutils tool on a symbolic link to another file, it would be useful to run Siddhesh's check (2) on symbolic links as well as real files.
Thank you both, I'll need to reserve more time for testing then.