binutils is vulnerable to CVE-2021-20197 (and various others)

OpenSubmitted by Léo Le Bouter.
Details
2 participants
  • Léo Le Bouter
  • Maxime Devos
Owner
unassigned
Severity
normal
L
L
Léo Le Bouter wrote on 26 Mar 21:41 +0100
(address . bug-guix@gnu.org)
669bea321d23f39ac5bb902dc930f4056f07ec78.camel@zaclys.net
CVE-2021-20197 18:15There is an open race window when writing output in the followingutilities in GNU binutils version 2.35 and earlier:ar, objcopy, strip,ranlib. When these utilities are run as a privileged user (presumablyas part of a script updating binaries across different users), anunprivileged user can trick these utilities into getting ownership ofarbitrary files through a symlink.
For the two versions packaged in GNU Guix we have:
$ ./pre-inst-env guix lint -c cve binutils@2.33gnu/packages/base.scm:584:2: binutils@2.33.1: probably vulnerable toCVE-2020-35493, CVE-2020-35494, CVE-2020-35495, CVE-2020-35496, CVE-2020-35507
$ ./pre-inst-env guix lint -c cve binutils@2.34gnu/packages/base.scm:571:2: binutils@2.34: probably vulnerable to CVE-2020-16590, CVE-2020-16591, CVE-2020-16592, CVE-2020-16593, CVE-2020-16599
Because they are also build tools for GNU Guix itself, we can't fixthis in grafts, a review of each and every CVE can be made to evaluatewhether we must fix it for GNU Guix's internal usage can be made, butalso we should update it and not use any vulnerable version anywhere sowe can be certain we didnt miss anything.
Can binutils be upgraded just like that? Or must it be upgraded intandem with GCC and friends?
Thank you,Léo
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFIvLi9gL+xax3g6RRaix6GvNEKYFAmBeRvAACgkQRaix6GvNEKZ8kRAAmAZr1kxoMaGXvAHujdj5yLe4s9U1+YqhBaUr4KI3bU0WKWZfy/+8vERbaDx453sxQFvIRW0g9DpwsJzL9n0+oft+g9C1KYaLgp63w6lhp0cdtkGKDJdYaJyEUulAS/F9W0OrWvp0uDeUikeBuAtniJ8lweApZn6VeMcfQ/WCIIMJ39lZ48mbKYhZUZXnyQGAEi4Jt+I7pEeoi+TBPeDIuN4YU4mivBiMMgrLnWZdEP1jKywBa5Lukb6GxMlmpkMdye8m8sTbuAmfZJ2IXvjcpwE3NgU05q6n6vOvuHyLuhSJJ5uOltob9I04HD1UeQOTGvaaDqNBFPpiM5v3abKJKv4ZjHD/MMXdUykAzAsDs93Ls7J5QF6avmu/ysfJpJNDNSy90Kld3e6VqO4P181Q3+kIVkzyeqbHOe6Md+FVuc7wMNl/oPy92H10zfcduy1klfSqqgPAUidL75Voti90mttPhAX7SYn7J2nwt0W2NJpbindrXhJwTX0jhbMAJDs0Osh+6StB3BDSsLknx3SN/Frj0UGf8UlelovASAarO9CmJ6W/w/5JPRkKYk/Npe2iejEzj+GbRhTZH9W5UMchdyoWS5UZw0eY2ArT/g0xdtdqdteKovnla4b0wai92AvvIuubGc7FeyA5qs788L8u4zhaPrYWiaVQQORUejGvzNM==jnN8-----END PGP SIGNATURE-----

L
L
Léo Le Bouter wrote on 26 Mar 21:55 +0100
(address . control@debbugs.gnu.org)
be44114ad75ba55c847243744ba8f47e2915606a.camel@zaclys.net
tags 47420 + securityquit
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFIvLi9gL+xax3g6RRaix6GvNEKYFAmBeSigACgkQRaix6GvNEKbr7BAAiMH8HQj4/CCrK2F5ZB5gBefvHEhlglk6HxWECwUrbnmkySEdCECh/3jQ6fDkXk6i0AKcP+BahRBpBUd5HANMYUvJk0aYNSoXozjFoxrLhEcWHLJ5bbTbhWTYauFFCXpD1FmNUDDuEMzO5MeltcSoiOnJG5rIHX+Y7Kwvr5U4yFQNTNunDS1/kHQSjuSvUMBRYwc22yNhfTXabswVOVwBXpcQUqnqgNWqpPslwoDve5IwCqN9ichkJnQgqWakYlAUR/6mcJDXH44C0whIHeH2/R0b0EwzvDWJpUPDNvrSTiRufJtP7l0IaORPP1XL3Y2A00HMmWMxntr1a7Qq1pmL+MC1SSSyh4NFf8vgyIpk71eMPJkF2j9CkUEzaOJJacNRjAqzPIGL0i2NlcWbNQT2PTDqAKPMKQMHz1fV+uu51ow3V6xbxuBP4kkILQlZ4b36NX0vMlEDw0085+IlPQ6SocXIsMY9H/pqe6QuKAa2XMQRM9j4jazCp+CKofNbWJAEX8V8Lkyy8g9NYcOZHJdKmnXqwdEW5Ptw7boFIBKXBpCz76JJlWLba124kyi5wsiLerD4fnYv0tFPs7FxedOFnlCU8cs3f/aLacdtFNnmUC0Mb70OqcM62HgEyYXnfwqfAuJXLn7crDsBhJ236EPMo8TV04KeQEp6bL7508WkFpI==8/r1-----END PGP SIGNATURE-----

L
L
Léo Le Bouter wrote on 26 Mar 22:56 +0100
(address . 47420@debbugs.gnu.org)
229d740c124ef1133bdaa032222302ac99e398a8.camel@zaclys.net
Another:
CVE-2021-20284 18:15A flaw was found in GNU Binutils 2.35.1, where there is a heap-basedbuffer overflow in _bfd_elf_slurp_secondary_reloc_section in elf.c dueto the number of symbols not calculated correctly. The highest threatfrom this vulnerability is to system availability.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFIvLi9gL+xax3g6RRaix6GvNEKYFAmBeWJAACgkQRaix6GvNEKYitxAAjjGVBnGZwORJcGfl4CN1J3kXS9Zzitt/E8VFzDYu20cardGBCyi86K7OlxCYS3/7OEZgwy1TFPfwTomBJU4AHQPSmqEOBaRPFXoL0q1s82qQlzHh/s1j65uL7hp/zSU2C+8IJmY9E93k1jgWx9CGP7fr9RkRvGl9tpAPmk3n9ctzBtyLO9Xn5eRymbV7DWWgbMTHwbeZfohpTrRSTSOuQI+wYxG33WzfRhjDYOwyUXhbI8av/CEFuVEcFlekTEgMzqfDduRAHLUEenIIj5nGX0WsZUjVz24a15jmjUFB5NjCszVxceOe4n6B9uiZaLVplAQjPYijQKV30yMJJjckvk5eZOyt+fsJN4EWFtLon9i7246+XM8sjfbBS4cZFveNxBWr8CbdJ5A+1iF9MyT7x2XM/BgatwAgzirYCd4RkjTrcXAVCgoj+ZVMJBY+QtPKO2lQHTU2fQxyf5u9t7cXNCybmHv5lUXe4XujtJ1T5MSBm06Krwnc535BaN2q6POjSM5cD51twR0AM0rnQk+e4r5/N6Ky4Mt0ZXZL7r5QSRSbfUYGDdkrlxz6y+AP0EoAD9vofEnzdXv8UznwPi0/HG3I+/0WqVqsYey5BvV1FEqjteWDh42mxvmpnR4wfOy6yBN1VCzBOwWBQVMRrzMHthunOxil240CKBoujwhXbzA==htsO-----END PGP SIGNATURE-----

M
M
Maxime Devos wrote on 27 Mar 00:00 +0100
d12edf9cd3c7a6779c25ccd40411c16292406e8d.camel@telenet.be
On Fri, 2021-03-26 at 21:41 +0100, Léo Le Bouter via Bug reports for GNU Guix wrote:
Toggle quote (8 lines)> CVE-2021-20197 18:15> 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.
At first I thought -- why would anyone run the binutils as root (or otherprivileged user)? Isn't it only used for *compiling* stuff? But thenI looked at the actual bug report:
https://sourceware.org/bugzilla/show_bug.cgi?id=26945
Apparently creating temporary files isn't done quite correctly.IIUC, on a shared guix system, a malicious user could use this bugto change the binary that would normally result from the innocentuser running "./configure && make" into something controlledby the malicious user.
Question: if I run "guix environment guix", do I get the packagesnormally used for building guix as-is, or the grafted versions?When I run "guix environment emacs", I see two lines "applying $N grafts",so I assume the latter.
Toggle quote (15 lines)> For the two versions packaged in GNU Guix we have:> > $ ./pre-inst-env guix lint -c cve binutils@2.33> gnu/packages/base.scm:584:2: binutils@2.33.1: probably vulnerable to> CVE-2020-35493, CVE-2020-35494, CVE-2020-35495, CVE-2020-35496, CVE-> 2020-35507> > $ ./pre-inst-env guix lint -c cve binutils@2.34> gnu/packages/base.scm:571:2: binutils@2.34: probably vulnerable to CVE-> 2020-16590, CVE-2020-16591, CVE-2020-16592, CVE-2020-16593, CVE-2020-> 16599
> Because they are also build tools for GNU Guix itself, we can't fix> this in grafts,
No, see next comment.
Toggle quote (5 lines)> a review of each and every CVE can be made to evaluate> whether we must fix it for GNU Guix's internal usage can be made, but> also we should update it and not use any vulnerable version anywhere so> we can be certain we didnt miss anything.
Guix itself only use binutils in the build containers, which (I presume)have their own temporary directories, so this shouldn't berelevant to Guix itself. However, grafts are still important for*developers*. See my first comment block.
Toggle quote (3 lines)> Can binutils be upgraded just like that? Or must it be upgraded in> tandem with GCC and friends?
I don't know, I guess you'll just have to try and read the release notes.In any case, upgrading packages seems a good idea (as long as it doesn'tcause world-rebuild or bootstrapping issues of course), even if thereweren't any security issues -- perhaps something to do on core-updates?.
Thanks for looking into these potential security issues,
Greetings,Maxime.
-----BEGIN PGP SIGNATURE-----
iI0EABYIADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYF5nmBccbWF4aW1lZGV2b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7k+PAQDTGO4qOQLRqmaQr72wSZvWxDNQAsiSw2Kt30W4AoVzVQEA6Oho2QtrfIFFs/vF6Ijq/WJOkVtHeZeqcInN6HzeEQU==aPRn-----END PGP SIGNATURE-----

?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send email to 47420@debbugs.gnu.org