Bug 28305

This one will have to wait... it got reverted in upstream 2.36.1 with the comment:

  In addition we found that a fix for a theoretical security
  vulnerability[1] was itself broken and could result in the archiver
  program "ar" misbehaving.  So we have chosen to revert the fix from
  the 2.36.1 release whilst the problem is properly resolved.

any news about this one upstream ?

CC: (none) => mageia

Cauldron binutils 2.36.1 seems to finally have stabilized with all the fixes that landed post 2.36.1, I will review them and "maybe" land it in mga8 too

ok so removing cauldron from targets

Whiteboard: MGA8TOO, MGA7TOO => MGA7TOO
Version: Cauldron => 8

Fedora has issued an advisory on April 21:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/RNBNDMJWZOQYCEZXENHBSM6DBZ332UZZ/

The issue is fixed upstream in 2.36.

Mageia 7 is also affected.

Summary: binutils new security issue CVE-2021-20197 => binutils new security issues CVE-2021-20197 and CVE-2021-3487

Mga7 is EOL.

Whiteboard: MGA7TOO => (none)

binutils 2.36.1 is now proven stable in Cauldron with all upstream post 2.36.1 fixes, so time to push it to mga8.

I wont push 2.36 to mga7 as there is ABI breakage...


SRPM:
binutils-2.36.1-1.mga8.src.rpm


i586:
binutils-2.36.1-1.mga8.i586.rpm
libbinutils-devel-2.36.1-1.mga8.i586.rpm


x86_64:
binutils-2.36.1-1.mga8.x86_64.rpm
lib64binutils-devel-2.36.1-1.mga8.x86_64.rpm

Assignee: tmb => qa-bugs
Whiteboard: MGA7TOO => (none)

Advisory, added to svn:


type: security
subject: Updated binutils packages fix security vulnerabilities
CVE:
 - CVE-2021-3487
 - CVE-2021-20197
src:
  8:
   core:
     - binutils-2.36.1-1.mga8
description: |
  This update provides binutils 2.36.1 and fixes atleast the following security
  issues:

  There's a flaw in the BFD library of binutils in versions before 2.36. An
  attacker who supplies a crafted file to an application linked with BFD, and
  using the DWARF functionality, could cause an impact to system availability
  by way of excessive memory consumption (CVE-2021-3487).

  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
  (CVE-2021-20197).

  For more info about the 2.36 update, see the sourceware link.
references:
 - https://bugs.mageia.org/show_bug.cgi?id=28305
 - https://sourceware.org/pipermail/binutils/2021-January/115071.html

Keywords: (none) => advisory

A couple of more fixes added, so new rpms list:


SRPM:
binutils-2.36.1-1.1.mga8.src.rpm


i586:
binutils-2.36.1-1.1.mga8.i586.rpm
libbinutils-devel-2.36.1-1.1.mga8.i586.rpm


x86_64:
binutils-2.36.1-1.1.mga8.x86_64.rpm
lib64binutils-devel-2.36.1-1.1.mga8.x86_64.rpm

PoC for CVE-2021-3487 requires ASAN, so no use to us; no PoC for CVE-2021-20197, although it has suggestions for testing here:
https://bugzilla.redhat.com/show_bug.cgi?id=1913743#c13

Test suite doesn't fully pass, as there are some "iamcu" tests which are unexpected failures; not sure if that's a regression or if it matters.  The suggestions there for testing ar, strip, objdump, and objcopy sound useful though.

mga8, x86_64

The utilities provided by binutils are listed here:
https://www.thegeekstuff.com/2017/01/gnu-binutils-commands/
and
https://en.wikipedia.org/wiki/GNU_Binutils

as, ar, ld, nm, objcopy, objdump, size, strings, strip, c++filt, addr2line, readelf, gprof, gold, nlmconv, ranlib

Mageia does not have nlmconv, and gold is ld.gold.
Before updating:
$ objcopy /bin/stellarium stellarium
$ ll /bin/stellarium stellarium
-rwxr-xr-x 1 root root 17411032 Dec 28  2020 /bin/stellarium*
-rwxr-xr-x 1 lcl  lcl  17411032 Jul 11 17:16 stellarium*
$ rm stellarium
$ su
# objcopy /bin/stellarium stellarium
# ll /bin/stellarium stellarium
-rwxr-xr-x 1 root root 17411032 Dec 28  2020 /bin/stellarium*
-rwxr-xr-x 1 root root 17411032 Jul 11 17:18 stellarium*

Logged in as su -
Created an archive in /root containing /bin/celestia and /bin/stellarium.
Copied that to a user's home directory and let user extract the files using ar.
Ownership went to the user.
$ ll astro.a
-rw-r--r-- 1 root root 18105320 Jul 11 17:50 astro.a
$ ar x astro.a
$ ll celestia stellarium
-rwxr-xr-x 1 lcl lcl   694096 Jul 11 17:54 celestia*
-rwxr-xr-x 1 lcl lcl 17411032 Jul 11 17:54 stellarium*

Not sure what is expected here in terms of ownership considering that all the files have world read permissions.
Maybe I should simply update and run previous tests.

CC: (none) => tarazed25

Updated the packages.
Ran some simple cli tests used before:

$ objdump -x /bin/pulseaudio
/bin/pulseaudio:     file format elf64-x86-64
/bin/pulseaudio
architecture: i386:x86-64, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0000000000408050

Program Header:
    PHDR off    0x0000000000000040 vaddr 0x0000000000400040 paddr 0x0000000000400040 align 2**3
         filesz 0x0000000000000268 memsz 0x0000000000000268 flags r--

$ objdump -f /bin/gcc
/bin/gcc:     file format elf64-x86-64
architecture: i386:x86-64, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0000000000407220

$ readelf -hl /bin/python
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
.....

$ nm -A -a -l -S -s --special-syms --synthetic -D /bin/stellarium > nm.txt
$ head nm.txt
/bin/stellarium:                 U acos@GLIBC_2.2.5
/bin/stellarium:                 U acosf@GLIBC_2.2.5
/bin/stellarium:000000000059b180 T acosf@plt
.....

$ strings /bin/lua | grep -i luaL
luaL_openlib
luaL_where
luaL_traceback
luaL_pushresultsize
.....

$ objcopy stellarium dummy
-rwxr-xr-x 1 lcl lcl 17411032 Jul 11 20:01 dummy*
-rwxr-xr-x 1 lcl lcl 17411032 Jul 11 18:23 stellarium*

$ ar qs reports.a report*
ar: creating reports.a
$ ar t reports.a
report.18987
report.25298
....

$ ar qf reports.a dummy
$ ar d reports.a report.18987
$ ar t reports.a
report.25298
report.27954
report.27954b
report.extra
dummy
$ rm dummy
$ ar x reports.a dummy
$ ll dummy
-rwxr-xr-x 1 lcl lcl 17411032 Jul 11  2021 dummy*

No regressions.  Good for x64.

Whiteboard: (none) => MGA8-64-OK

Validating.

Keywords: (none) => validated_update
CC: (none) => andrewsfarm, sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2021-0341.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED

This update also fixed CVE-2020-35448 and CVE-2021-20284 (fixed in 2.36):
https://lists.suse.com/pipermail/sle-security-updates/2021-November/009687.html