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

[Mark H Weaver]

Six days ago, I wrote:

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

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

[Mark H Weaver]

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 
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(+)

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 .

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

[Mark H Weaver]

Hi Maxime,

Maxime Devos  writes:

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

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

[Maxime Devos]

Leo Famulari schreef op vr 05-11-2021 om 12:23 [-0400]:
> On Fri, Nov 05, 2021 at 05:14:13AM +, 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.

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

[Leo Famulari]

On Fri, Nov 05, 2021 at 05:14:13AM +, 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 :-/

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)

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

[phodina via Bug reports for GNU Guix]

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.

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

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

[Maxime Devos]

On Fri, 2021-03-26 at 22:30 +0100, Léo Le Bouter via Bug reports for GNU Guix 
wrote:
> CVE-2021-2019318: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’).

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

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

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


signature.asc
Description: This is a digitally signed message part

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

[Léo Le Bouter via Bug reports for GNU Guix]

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.


signature.asc
Description: This is a digitally signed message part