tar is vulnerable to CVE-2021-20193

  • Done
  • quality assurance status badge
Details
5 participants
  • Leo Famulari
  • Léo Le Bouter
  • Maxime Devos
  • Mark H Weaver
  • phodina
Owner
unassigned
Submitted by
Léo Le Bouter
Severity
normal
L
L
Léo Le Bouter wrote on 26 Mar 2021 22:30
(address . bug-guix@gnu.org)
520e2097011aae1bfd9c20278e27e25813517b42.camel@zaclys.net
CVE-2021-20193 18:15
A flaw was found in the src/list.c of tar 1.33 and earlier. This flaw
allows an attacker who can submit a crafted input file to tar to cause
uncontrolled consumption of memory. The highest threat from this
vulnerability is to system availability.

Patch available here:

Unreleased for now.

We can probably apply it in core-updates now, we should fix it in
master also, since grafts don't apply to GNU Guix builds is that OK?

GNU Guix packages don't unpack arbitrary tarballs since we hardcode
hashes for verification, but still.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEFIvLi9gL+xax3g6RRaix6GvNEKYFAmBeUpEACgkQRaix6GvN
EKaWrA//Y2BwKy6QO9/cWqwZRS7BEPianKnio3VqzdGkgCuRi+9GYlyHVeK9wSgC
/TZWz1xB/6pqLJFlH6dKNr9cmEjxVFJRGRNRyfvHgtHwzf/5/mYmcYYHA4d2Ccl4
9+UU1NZCRZSZkjFrVMGZ682HIUe5CQ3MzOVWxbaSdo1jecFnk/pHkDqWr8tJKCFL
vo9OHLmhHVHZcExStWJXDM37iSyHw+XAumzURci/sDZy7lxmh6QhtRPjnKaKDaI6
+ppWjaY8kDHWnbRRm5sdMsKNXXeGEbx10ATfay5v3PWqZoi63nGF1NVgBmM57gE1
L8dwBJtt8apzKOdiulc77Wrc8isdWhp/qE9078gKQdOnBBiG8cdzbnMuxrTBnL12
afDOkfH25IJ+Uv2c4ZQdg/O6J9bqIj/Fw5yIIIbCviHil3mV4A2LczBOD3rOol5F
D5JkrHJ/Nx7lbPviyt/fEye4sqBaiy8PlZxvLmp02WrDXTUEaxCTE1Q8Jga94/Tk
jneMtuXRa1ivj81GP81bs31C36+cz+aCBcsz0Xp2MCPHOv43BwxLwvAMxvq/nQdZ
AZNAYsUCSEaxklhjrl4kGwXteBf/qMgDp5iYBmdGhS+vMggapgXZqfbkJ04kq2ny
JaYZ+i3iPdzRxFYyTG7L3vzkBuY5E519NrNO8rSiYjlUCjCnICs=
=e+Y2
-----END PGP SIGNATURE-----


L
L
Léo Le Bouter wrote on 26 Mar 2021 22:35
(address . control@debbugs.gnu.org)
2559cf953da6495f033378d37af686c1d23b43b5.camel@zaclys.net
tags 47422 + security
quit
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEFIvLi9gL+xax3g6RRaix6GvNEKYFAmBeU4kACgkQRaix6GvN
EKb1Dw/+MbT5YX4nxe3fa6/q9raZyCDdTbTGsdeqFq7qVPreVgZ3cp/0ABjyRHWy
wWhsRoJbdd05ggoT+xwVrUN1t7UZ1KOrq6/fmfY7ARTiWvjWeIQj4w9iCIUeLid4
jj8QMn6AVkQE2xVbNZGp7OszNAhroG4RhHW/IJ+IXrBCq2Abo+QT+F92JJWQzyp7
sUS/EG0+ZtdL2gsBDZDlTdPcKK5qulTdJPv3ye+AU0l3oQPoA9FUGrANudCNp+Rf
4jvS17J+Vb6QOr/Aa6MnDA3AVVHpvXbnymJHrwshhqQ81lsR8ol4zq/tqArCWU/V
6bb1G7+Ze8dQtacdtX0F84k1GmxgWn0LtX0oPaEBboPfyzY30FRD8XawuZmcvOKu
UO6NAQIviwtnyI6Pdm3Fx0e4U1HSNjHswJ94NPXmKa0lzkOyv+SVFvTJDqeqkp/s
BUTqDZvm9tvw7kg/8vskvutcIvRdMDOkF3qZRsv6nTaxc63LSa0fGFJ7nV0o8Dg7
piLcD2MjAV3BZ6iF1dpqpMdOI5x0POTPWD67IAV7s5SrDSmGugyCZ8H5fn5VRVV1
1sbMbEgiPbnQGuQjPgPuAN32bN3Y+SpAe65KT2C2LKetyuV/sR2fHfO+dtXc2NBj
U4G/LEoyd001AmMbPEbDiq57S9HpbzLNeIDYPUz6L7QimHPX02E=
=NG29
-----END PGP SIGNATURE-----


M
M
Maxime Devos wrote on 26 Mar 2021 23:40
1bc26f41f7a30bb04777b5a654acddbcfc3ea54c.camel@telenet.be
On Fri, 2021-03-26 at 22:30 +0100, Léo Le Bouter via Bug reports for GNU Guix wrote:
Toggle quote (12 lines)
> CVE-2021-20193 18:15

> A flaw was found in the src/list.c of tar 1.33 and earlier. This flaw
> allows an attacker who can submit a crafted input file to tar to cause
> uncontrolled consumption of memory. The highest threat from this
> vulnerability is to system availability.
>
> Patch available here:
> https://git.savannah.gnu.org/cgit/tar.git/commit/?id=d9d4435692150fa8ff68e1b1a473d187cc3fd777
>
> Unreleased for now.

There has been a 1.34 release (a git tag is missing, but see
https://git.savannah.gnu.org/cgit/tar.git/log/‘maint: 1.34 announcement update’).

Toggle quote (2 lines)
> We can probably apply it in core-updates now,

That's done already

Toggle quote (2 lines)
> we should fix it in master also, since grafts don't apply to GNU Guix builds is that OK?

Technically, there won't be any trouble (except increased time spent grafting I guess),
but ...

Toggle quote (3 lines)
> GNU Guix packages don't unpack arbitrary tarballs since we hardcode
> hashes for verification, but still

It's ‘merely’ a denial-of-service attack. Perhaps relevant to Software Heritage
though (idk if they use Guix). So no big rush, but still nice to fix.

Thanks for looking at this (& other potential security issues),
Greetings, Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYIADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYF5iwRccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7r/eAQDyc6qat9RI4aaTAOy5C3e28f/c
/TqfotO3J0egywhzXQD9Fykp3dvj/EiKCGagipnNiJt5zT0TzPr4MsLBVlkqVA8=
=jYVF
-----END PGP SIGNATURE-----


P
P
phodina wrote on 5 Nov 2021 06:14
RE: tar is vulnerable to CVE-2021-20193
(name . 47422@debbugs.gnu.org)(address . 47422@debbugs.gnu.org)
ysdJZxCdgMKsc9Tq-LKYLg_OgwwdXBljXBYTzfupOKMOshTTI34ijmXx0D8acxWF7OYW9NFXOLFLOVuV-NT-T3IyIjxCU0RboaItON_XjFY=@protonmail.com
Hi,

here's patch for the master branch as I'm not sure what is the roadmap for merging core-updates into master.

The obvious downside is that the update triggers large rebuild of core packages :-/

---8<-------------cut here----------start------------>8----

[PATCH] gnu: tar: Update to 1.34.

* gnu/package/base.scm (tar): Update to 1.34.

Toggle diff (21 lines)
diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index ea2e102c15..6ebe30464e 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -179,14 +179,14 @@ (define-public sed
(define-public tar
   (package
    (name "tar")
-   (version "1.32")
+   (version "1.34")
    (source (origin
             (method url-fetch)
             (uri (string-append "mirror://gnu/tar/tar-"
                                 version ".tar.xz"))
             (sha256
              (base32
-              "1n7xy657ii0sa42zx6944v2m4v9qrh6sqgmw17l3nch3y43sxlyh"))
+              "0a0x87anh9chbi2cgcyy7pmnm5hzk4yd1w2j8gm1wplwhwkbvgk3"))
             (patches (search-patches "tar-skip-unreliable-tests.patch"
                                      "tar-remove-wholesparse-check.patch"))))
    (build-system gnu-build-system)
--
2.33.1
L
L
Leo Famulari wrote on 5 Nov 2021 17:23
Re: bug#47422: tar is vulnerable to CVE-2021-20193
(name . phodina via Bug reports for GNU Guix)(address . bug-guix@gnu.org)(name . 47422@debbugs.gnu.org)(address . 47422@debbugs.gnu.org)
YYVakIUhmYGjGLvW@jasmine.lan
On Fri, Nov 05, 2021 at 05:14:13AM +0000, phodina via Bug reports for GNU Guix wrote:
Toggle quote (4 lines)
> here's patch for the master branch as I'm not sure what is the roadmap for merging core-updates into master.
>
> The obvious downside is that the update triggers large rebuild of core packages :-/

Right, it's not feasible to apply this patch on the master branch, for
that reason. And, it would not only require rebuilding core packages,
but every single package, if I understand correctly.

For Guix's internal use of tar, it seems that CVE-2021-20193 [0] is not
a problem:

"This flaw allows an attacker who can submit a crafted input file to tar
to cause uncontrolled consumption of memory. The highest threat from
this vulnerability is to system availability."

When tar is used by Guix to unpack an upstream tarball, a Guix developer
has already tested that it's possible to unpack the tarball without
making the system unavailable. And Guix checks the source hash before
unpacking the tarball. Does this evaluation seem correct?

For use of tar by Guix users, we could add a new package 'tar-1.34' and
arrange so that `guix install tar` selects it instead of tar@1.32, and
so that whatever tar is provided by default on Guix System [1] is
tar-1.34. And we would also take care to properly undo this workaround
on the core-updates branch.

[1] I *think* that is handled by ((gnu system) %base-packages-utils)
M
M
Maxime Devos wrote on 5 Nov 2021 17:50
82db7b68b4e9cc3037122cc45678f04eac97d810.camel@telenet.be
Leo Famulari schreef op vr 05-11-2021 om 12:23 [-0400]:
Toggle quote (24 lines)
> On Fri, Nov 05, 2021 at 05:14:13AM +0000, phodina via Bug reports for
> GNU Guix wrote:
> > here's patch for the master branch as I'm not sure what is the
> > roadmap for merging core-updates into master.
> >
> > The obvious downside is that the update triggers large rebuild of
> > core packages :-/
>
> [...]
>
> "This flaw allows an attacker who can submit a crafted input file to
> tar
> to cause uncontrolled consumption of memory. The highest threat from
> this vulnerability is to system availability."
>
> [...]
>
> For use of tar by Guix users, we could add a new package 'tar-1.34'
> and
> arrange so that `guix install tar` selects it instead of tar@1.32,
> and
> so that whatever tar is provided by default on Guix System [1] is
> tar-1.34.

I don't think this is sufficient, because some packages keep
references to 'tar', e.g. 'hdup'. A solution would be registering
the updated tar as a replacement of the somewhat vulnerable tar:

(define-public tar
(package
(name "tar")
(version "1.32")
(replacement tar/fixed)
...))

(define-public tar/fixed
(package
(inherit tar)
(version "1.34")
(source ...)))

Greetings,
Maxime.
--
not hacking on guix for a while, only occassionally looking at IRC logs
and bug reports. E-mails are unsigned until backup is located.
M
M
Mark H Weaver wrote on 5 Nov 2021 21:15
8735oauzmx.fsf@netris.org
Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

Toggle quote (10 lines)
> Leo Famulari schreef op vr 05-11-2021 om 12:23 [-0400]:
>> For use of tar by Guix users, we could add a new package 'tar-1.34'
>> and arrange so that `guix install tar` selects it instead of
>> tar@1.32, and so that whatever tar is provided by default on Guix
>> System [1] is tar-1.34.
>
> I don't think this is sufficient, because some packages keep
> references to 'tar', e.g. 'hdup'. A solution would be registering
> the updated tar as a replacement of the somewhat vulnerable tar:

I think this is the better approach. Leo's analysis is correct, but
there are a few problems:

(1) I guess that most Guix users don't install 'tar' manually, but
rather depend on the fact that 'tar' is included in %base-packages,
which references 'tar' by its variable name.

(2) Even for users who explicitly ask for 'tar', if they reference it by
its variable name, they would still get the vulnerable version.
That includes users (such as myself) who manage their profiles
declaratively, i.e. using "guix package --manifest".

(3) As Maxime pointed out, it's possible that some packages might retain
a reference to 'tar' to be used at runtime.

However, someone would need to test to make sure that after grafting
'tar', they can successfully rebuild their system and boot into it.
Hopefully the code in 'commencement' deals properly with a grafted
'tar', but that should be checked.

I won't be able to work on this today, so hopefully someone else can
take care of it. Otherwise, I'll do it tomorrow.

Thanks!
Mark

--
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about https://stallmansupport.org.
M
M
Mark H Weaver wrote on 6 Nov 2021 19:12
8735o9b1a8.fsf@netris.org
Hi,

Here's a proposed fix, which I've tested on my own system.
Are there any objections to pushing this to 'master'?

Thanks,
Mark
From 5737b91e9979c7df2a76b033f38871c2326ab0f1 Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@netris.org>
Date: Sat, 6 Nov 2021 05:52:24 -0400
Subject: [PATCH] gnu: tar: Replace with 1.34 [fixes CVE-2021-20193].

* gnu/packages/base.scm (tar)[replacement]: New field.
(tar-1.34): New variable.
---
gnu/packages/base.scm | 16 ++++++++++++++++
1 file changed, 16 insertions(+)

Toggle diff (36 lines)
diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index ea2e102c15..77731d3720 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -180,6 +180,7 @@ implementation offers several extensions over the standard utility.")
(package
(name "tar")
(version "1.32")
+ (replacement tar-1.34)
(source (origin
(method url-fetch)
(uri (string-append "mirror://gnu/tar/tar-"
@@ -234,6 +235,21 @@ standard utility.")
(license gpl3+)
(home-page "https://www.gnu.org/software/tar/")))
+(define-public tar-1.34 ; fixes CVE-2021-20193
+ (package
+ (inherit tar)
+ (version "1.34")
+ (source (origin
+ (method url-fetch)
+ (uri (string-append "mirror://gnu/tar/tar-"
+ version ".tar.xz"))
+ (sha256
+ (base32
+ "0a0x87anh9chbi2cgcyy7pmnm5hzk4yd1w2j8gm1wplwhwkbvgk3"))
+ (patches
+ (search-patches "tar-skip-unreliable-tests.patch"
+ "tar-remove-wholesparse-check.patch"))))))
+
(define-public patch
(package
(name "patch")
--
2.31.1
--
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about https://stallmansupport.org.
M
M
Mark H Weaver wrote on 12 Nov 2021 08:54
87h7ch24hg.fsf@netris.org
Six days ago, I wrote:

Toggle quote (3 lines)
> Here's a proposed fix, which I've tested on my own system.
> Are there any objections to pushing this to 'master'?

I've now pushed this to 'master', commit
33a80e111096b05af3d60576dfcb2d67099dc60e.
I'm closing this bug now.

Thanks!
Mark

--
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about https://stallmansupport.org.
Closed
?
Your comment

This issue is archived.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 47422
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch