tar is vulnerable to CVE-2021-20193

Done

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

Debbugs page

Léo Le Bouter wrote on 26 Mar 2021 14:30

Recipients:(address . bug-guix@gnu.org)

Message-ID: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:

https://git.savannah.gnu.org/cgit/tar.git/commit/?id=d9d4435692150fa8ff68e1b1a473d187cc3fd777

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.

Léo Le Bouter wrote on 26 Mar 2021 14:35

Recipients:(address . control@debbugs.gnu.org)

Message-ID:2559cf953da6495f033378d37af686c1d23b43b5.camel@zaclys.net

tags 47422 + security

quit

Maxime Devos wrote on 26 Mar 2021 15:40

Recipients:

Message-ID: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

(https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/base.scm?id=core-updates#n178)

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

phodina wrote on 4 Nov 2021 22:14

RE: tar is vulnerable to CVE-2021-20193

Recipients:(name . 47422@debbugs.gnu.org)(address . 47422@debbugs.gnu.org)

Message-ID: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

Leo Famulari wrote on 5 Nov 2021 09:23

Re: bug#47422: tar is vulnerable to CVE-2021-20193

Recipients:(name . phodina via Bug reports for GNU Guix)(address . bug-guix@gnu.org)(name . 47422@debbugs.gnu.org)(address . 47422@debbugs.gnu.org)

Message-ID: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.

[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20193

[1] I *think* that is handled by ((gnu system) %base-packages-utils)

Maxime Devos wrote on 5 Nov 2021 09:50

Recipients:

Message-ID: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.

Mark H Weaver wrote on 5 Nov 2021 13:15

Recipients:

Message-ID: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.

Mark H Weaver wrote on 6 Nov 2021 11:12

Recipients:

Message-ID: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.

Mark H Weaver wrote on 11 Nov 2021 23:54

Recipients:

Message-ID: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@patchwise.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

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date