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. Reference: https://sourceware.org/bugzilla/show_bug.cgi?id=26945
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.
Upstream patches: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=365f5fb6d0f0da83817431a275e99e6f6babbe04 https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1a1c3b4cc17687091cff5a368bd6f13742bcfdf8 https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=014cc7f849e8209623fc99264814bce7b3b6faf2
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): https://sourceware.org/bugzilla/show_bug.cgi?id=27270 https://sourceware.org/bugzilla/show_bug.cgi?id=27284 There's a fourth patch under review to fix them: https://sourceware.org/pipermail/binutils/2021-February/115161.html
Hi Miloš, 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. Cheers Nick
Thank you both, I'll need to reserve more time for testing then.
The fix for this patch (binutils-CVE-2021-20197.patch) breaks mingw-binutils, see https://bugzilla.redhat.com/show_bug.cgi?id=1951278#c3
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:4364 https://access.redhat.com/errata/RHSA-2021:4364
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2021-20197