all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#47420: binutils is vulnerable to CVE-2021-20197 (and various others)
@ 2021-03-26 20:41 Léo Le Bouter via Bug reports for GNU Guix
  2021-03-26 21:56 ` Léo Le Bouter via Bug reports for GNU Guix
  2021-03-26 23:00 ` Maxime Devos
  0 siblings, 2 replies; 4+ messages in thread
From: Léo Le Bouter via Bug reports for GNU Guix @ 2021-03-26 20:41 UTC (permalink / raw)
  To: 47420

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

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.

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, 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.

Can binutils be upgraded just like that? Or must it be upgraded in
tandem with GCC and friends?

Thank you,
Léo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#47420: binutils is vulnerable to CVE-2021-20197 (and various others)
  2021-03-26 20:41 bug#47420: binutils is vulnerable to CVE-2021-20197 (and various others) Léo Le Bouter via Bug reports for GNU Guix
@ 2021-03-26 21:56 ` Léo Le Bouter via Bug reports for GNU Guix
  2021-03-26 23:00 ` Maxime Devos
  1 sibling, 0 replies; 4+ messages in thread
From: Léo Le Bouter via Bug reports for GNU Guix @ 2021-03-26 21:56 UTC (permalink / raw)
  To: 47420

[-- Attachment #1: Type: text/plain, Size: 299 bytes --]

Another:

CVE-2021-20284	18:15
A flaw was found in GNU Binutils 2.35.1, where there is a heap-based
buffer overflow in _bfd_elf_slurp_secondary_reloc_section in elf.c due
to the number of symbols not calculated correctly. The highest threat
from this vulnerability is to system availability.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#47420: binutils is vulnerable to CVE-2021-20197 (and various others)
  2021-03-26 20:41 bug#47420: binutils is vulnerable to CVE-2021-20197 (and various others) Léo Le Bouter via Bug reports for GNU Guix
  2021-03-26 21:56 ` Léo Le Bouter via Bug reports for GNU Guix
@ 2021-03-26 23:00 ` Maxime Devos
  2022-03-23  2:31   ` Maxim Cournoyer
  1 sibling, 1 reply; 4+ messages in thread
From: Maxime Devos @ 2021-03-26 23:00 UTC (permalink / raw)
  To: Léo Le Bouter, 47420

[-- Attachment #1: Type: text/plain, Size: 2858 bytes --]

On Fri, 2021-03-26 at 21:41 +0100, Léo Le Bouter via Bug reports for GNU Guix wrote:
> 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 other
privileged user)?  Isn't it only used for *compiling* stuff?  But then
I 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 bug
to change the binary that would normally result from the innocent
user running "./configure && make" into something controlled
by the malicious user.

Question: if I run "guix environment guix", do I get the packages
normally 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.

> 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.

>  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 be
relevant to Guix itself.  However, grafts are still important for
*developers*.  See my first comment block.

> 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't
cause world-rebuild or bootstrapping issues of course), even if there
weren't any security issues -- perhaps something to do on core-updates?.

Thanks for looking into these potential security issues,

Greetings,
Maxime.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#47420: binutils is vulnerable to CVE-2021-20197 (and various others)
  2021-03-26 23:00 ` Maxime Devos
@ 2022-03-23  2:31   ` Maxim Cournoyer
  0 siblings, 0 replies; 4+ messages in thread
From: Maxim Cournoyer @ 2022-03-23  2:31 UTC (permalink / raw)
  To: Maxime Devos; +Cc: 47420-done

Hi,

Maxime Devos <maximedevos@telenet.be> writes:

> On Fri, 2021-03-26 at 21:41 +0100, Léo Le Bouter via Bug reports for GNU Guix wrote:
>> 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.

Our current version of binutilsis now 2.37, immune to the CVE reported
here.

Thanks for the report!

Closing.

Maxim




^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-03-23  2:32 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-03-26 20:41 bug#47420: binutils is vulnerable to CVE-2021-20197 (and various others) Léo Le Bouter via Bug reports for GNU Guix
2021-03-26 21:56 ` Léo Le Bouter via Bug reports for GNU Guix
2021-03-26 23:00 ` Maxime Devos
2022-03-23  2:31   ` Maxim Cournoyer

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.