[arch-dev-public] strip command of binutils 2.36 changes ownership in fakeroot 1.25.3

[Levente Polyak]

Hi all,

We were recently made aware by a bug report [1] that when the strip
executable from binutils 2.36-3 in [core] is run within a fakeroot, it
does not keep the correct file ownership during stripping, but
indiscriminately assigns ownership to root:root instead. This causes
issues with executables that make use of setuid, setgid or capabilities
and should be owned by a user other than root. The incorrect ownership
in combination with these attributes could lead to a potential local
privilege escalation. The issue is caused by the fact that binutils
2.36-3 is compiled using glibc 2.33, thus using a new syscall that
fakeroot does not intercept correctly [2].

Following the bug report, pacman was patched [3] to correctly handle
file ownership during stripping itself, instead of relying on binutils
to restore the correct ownership. Additionally, all packages built with
binutils 2.36 were scanned for usage of setuid, setgid or capabilities
(either during packaging or using an install script). A small number of
packages was found, but these turned out to be false positives or
operated on files that are already supposed to be owned by root anyway.
We conclude that users were not exposed to any vulnerable packages
affected by this issue [4].

Note that the fix to pacman only covers the stripping process run
automatically by pacman. If strip is run inside a PKGBUILD, either
manually or as part of a build system like qmake [5], file ownership
will still be set to root:root. Please double-check all your packages to
see whether they execute strip on files that should not be owned by
root. Since it is unclear when fakeroot will be updated to work with
glibc 2.33, permissions will have to be fixed manually after running
strip by an appropriate chown call in this case. Note however that
generally strip should not be run inside a PKGBUILD at all as it breaks
creating debug packages, and should be disabled if run by default by the
build system.

[1] https://bugs.archlinux.org/task/69584
[2] https://sourceware.org/pipermail/binutils/2021-February/115252.html
[3]
https://git.archlinux.org/pacman.git/commit/?id=88d054093c1c99a697d95b26bd9aad5bc4d8e170
[4] https://md.archlinux.org/TAiOYgKzQl-1cJxDaQlB_g
[5]
https://github.com/archlinux/svntogit-packages/commit/138105f29cb29d7b7ebdff70d3da4cf7b339a874

Greetings,

Arch Linux Security Team

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20210210/9521896d/attachment.sig>