[PATCH 1/1] gnu: libarchive: Fix a potential security issue.

  • Done
  • quality assurance status badge
Details
5 participants
  • Efraim Flashner
  • John Kehayias
  • Leo Famulari
  • Ludovic Courtès
  • pelzflorian (Florian Pelz)
Owner
unassigned
Submitted by
Leo Famulari
Severity
normal
Merged with
L
L
Leo Famulari wrote on 31 Mar 22:44 +0200
(address . guix-patches@gnu.org)
7a74261a419e9127887bc9ea096294e42156cce1.1711917891.git.leo@famulari.name

* gnu/packages/backup.scm (libarchive)[replacement]: New field.
(libarchive/fixed): New variable.
* gnu/packages/patches/libarchive-remove-potential-backdoor.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.

Change-Id: I939e9b842b10d1a78125da4a4599c38d9c037079
---
gnu/local.mk | 1 +
gnu/packages/backup.scm | 19 ++++++++
...libarchive-remove-potential-backdoor.patch | 47 +++++++++++++++++++
3 files changed, 67 insertions(+)
create mode 100644 gnu/packages/patches/libarchive-remove-potential-backdoor.patch

Toggle diff (104 lines)
diff --git a/gnu/local.mk b/gnu/local.mk
index f2b480bded..68c6851402 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1575,6 +1575,7 @@ dist_patch_DATA = \
%D%/packages/patches/liba52-use-mtune-not-mcpu.patch \
%D%/packages/patches/libaio-32bit-test.patch \
%D%/packages/patches/libaio-riscv-test5.patch \
+ %D%/packages/patches/libarchive-remove-potential-backdoor.patch \
%D%/packages/patches/libbase-fix-includes.patch \
%D%/packages/patches/libbase-use-own-logging.patch \
%D%/packages/patches/libbonobo-activation-test-race.patch \
diff --git a/gnu/packages/backup.scm b/gnu/packages/backup.scm
index 604102bc7b..5dfdfe7dd4 100644
--- a/gnu/packages/backup.scm
+++ b/gnu/packages/backup.scm
@@ -259,6 +259,7 @@ (define-public hdup
(define-public libarchive
(package
(name "libarchive")
+ (replacement libarchive/fixed)
(version "3.6.1")
(source
(origin
@@ -347,6 +348,24 @@ (define-public libarchive
@command{bsdcat}, @command{bsdcpio} and @command{bsdtar} commands.")
(license license:bsd-2)))
+(define-public libarchive/fixed
+ (package
+ (inherit libarchive)
+ (version "3.6.1")
+ (source
+ (origin
+ (method url-fetch)
+ (uri (list (string-append "https://libarchive.org/downloads/libarchive-"
+ version ".tar.xz")
+ (string-append "https://github.com/libarchive/libarchive"
+ "/releases/download/v" version "/libarchive-"
+ version ".tar.xz")))
+ (patches (search-patches "libarchive-remove-potential-backdoor.patch"))
+ (sha256
+ (base32
+ "1rj8q5v26lxxr8x4b4nqbrj7p06qvl91hb8cdxi3xx3qp771lhas"))))))
+
+
(define-public rdup
(package
(name "rdup")
diff --git a/gnu/packages/patches/libarchive-remove-potential-backdoor.patch b/gnu/packages/patches/libarchive-remove-potential-backdoor.patch
new file mode 100644
index 0000000000..2b9a9e2ffe
--- /dev/null
+++ b/gnu/packages/patches/libarchive-remove-potential-backdoor.patch
@@ -0,0 +1,47 @@
+Remove code added by 'JiaT75', the malicious actor that backdoored `xz`:
+
+https://github.com/libarchive/libarchive/pull/2101
+
+At libarchive, they are reviewing all code contributed by this actor:
+
+https://github.com/libarchive/libarchive/issues/2103
+
+See the original disclosure and subsequent discussion for more
+information about this incident:
+
+https://seclists.org/oss-sec/2024/q1/268
+
+Patch copied from upstream source repository:
+
+https://github.com/libarchive/libarchive/pull/2101/commits/e200fd8abfb4cf895a1cab4d89b67e6eefe83942
+
+From 6110e9c82d8ba830c3440f36b990483ceaaea52c Mon Sep 17 00:00:00 2001
+From: Ed Maste <emaste@freebsd.org>
+Date: Fri, 29 Mar 2024 18:02:06 -0400
+Subject: [PATCH] tar: make error reporting more robust and use correct errno
+ (#2101)
+
+As discussed in #1609.
+---
+ tar/read.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/tar/read.c b/tar/read.c
+index af3d3f42..a7f14a07 100644
+--- a/tar/read.c
++++ b/tar/read.c
+@@ -371,8 +371,9 @@ read_archive(struct bsdtar *bsdtar, char mode, struct archive *writer)
+ if (r != ARCHIVE_OK) {
+ if (!bsdtar->verbose)
+ safe_fprintf(stderr, "%s", archive_entry_pathname(entry));
+- fprintf(stderr, ": %s: ", archive_error_string(a));
+- fprintf(stderr, "%s", strerror(errno));
++ safe_fprintf(stderr, ": %s: %s",
++ archive_error_string(a),
++ strerror(archive_errno(a)));
+ if (!bsdtar->verbose)
+ fprintf(stderr, "\n");
+ bsdtar->return_value = 1;
+--
+2.41.0
+
--
2.41.0
L
L
Leo Famulari wrote on 31 Mar 22:50 +0200
(no subject)
(address . control@debbugs.gnu.org)
ZgnMlFiqNWIe5-9f@jasmine.lan
merge 70114 70113
L
L
Leo Famulari wrote on 31 Mar 22:51 +0200
SECURITY: Xz backdoor / JiaT75 cleanup for libarchive
(address . 70113@debbugs.gnu.org)
ZgnMxDxsDkjr-mEa@jasmine.lan
Attachment: file
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEaEByLu7k06ZO5T6saqwZY3V/R/8FAmYJzL0ACgkQaqwZY3V/
R//QwxAAh/AdfB1HpLEpq/ZLOqO/SJVPfEfpyDyvNF8uMUOz34Yt1KBNGQ8XLgJO
0UlhFil1WXxt3+goK85W7fjba1lYI8VZsNKX0K6FpYf3ql7+SywxH9GiWNEBw/Zz
ZuIHa6NKM+lEnDJ9nxWjZ/wOjNiwYFHUcqSWLtUWlHSK8uzwBlT5/G3Y6dCN6uFS
erLH8Eq6aZ0c+F+C86MEjEhN/mYan9+eKMV/d7j//QIhm8oCHVygJYaf7iexus1m
XN3khCuFAsQMmYwCTwpCEgd+iX/d0TyHVHzcS1LLwTu3ZD7Yut1DnLOewKGOoeSg
yBexVfgIYcrxZDYLgNwp8OxvPF/sa3jgsBSQQVuMliwfOysGZrHedPElqQ2TslYy
JvhQ2O4DK++RqT/n/j6tarv4XUhKsvZ+Hfeu690tHEAYdGC77Fv+hIjauEgzVNv3
lPZjMLCfv2ihwdUavhZWpHVt86Mftu7Aez3XwmsPLEU2lrCpFA6vsuhouiUmXxzU
AP6Yx/Qbf195ENgIfOq3d+ZQtA8No1VOSU/wOke21ZhR5AJZN1VXxgzkL3+ese//
pqx0rh4xO/7fdFOdhv4c49bBq5F3LisXMkeZXy2DaB+j8i8Fcfw4ZSC2m9TcfPd9
XFEdk8JMvuBfh4y1SW7CYU2mg9V108aAMJOG1pzD1uDOE4LIRes=
=nxqY
-----END PGP SIGNATURE-----


J
J
John Kehayias wrote on 2 Apr 05:23 +0200
Re: [bug#70113] [PATCH 1/1] gnu: libarchive: Fix a potential security issue.
(name . Leo Famulari)(address . leo@famulari.name)
87il10wipx.fsf@protonmail.com
Hi Leo,

On Sun, Mar 31, 2024 at 04:44 PM, Leo Famulari wrote:

Toggle quote (8 lines)
>
> * gnu/packages/backup.scm (libarchive)[replacement]: New field.
> (libarchive/fixed): New variable.
> * gnu/packages/patches/libarchive-remove-potential-backdoor.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add it.
>

Overall changes look good, but I have not had a chance to try it locally
(building or dependents).

[...]

Toggle quote (13 lines)
> +(define-public libarchive/fixed
> + (package
> + (inherit libarchive)
> + (version "3.6.1")
> + (source
> + (origin
> + (method url-fetch)
> + (uri (list (string-append "https://libarchive.org/downloads/libarchive-"
> + version ".tar.xz")
> + (string-append "https://github.com/libarchive/libarchive"
> + "/releases/download/v" version "/libarchive-"
> + version ".tar.xz")))

In light of the xz backdoor, perhaps we should just do a git checkout of
the v3.6.1 tag rather than the tarballs? Assuming that works, of course.

I haven't had a chance to look at potential ABI changes, but perhaps at
least v3.6.2 is graftable? That also lists a security update (as well as
later versions).

Or, if it is easier and this is tested on your end, let's push this and
do an upgrade to the latest on a branch. I would volunteer mesa-updates,
but Cuirass has been stuck all day not building anything, so I don't
know what will end up being quickest (which branch or a new one).

Thanks for the quick work!
John
E
E
Efraim Flashner wrote on 2 Apr 15:24 +0200
(name . John Kehayias)(address . john.kehayias@protonmail.com)
ZgwG9F56NpS1YGt-@3900XT
On Tue, Apr 02, 2024 at 03:23:44AM +0000, John Kehayias via Guix-patches via wrote:
Toggle quote (16 lines)
> Hi Leo,
>
> On Sun, Mar 31, 2024 at 04:44 PM, Leo Famulari wrote:
>
> > https://github.com/libarchive/libarchive/pull/2101
> >
> > * gnu/packages/backup.scm (libarchive)[replacement]: New field.
> > (libarchive/fixed): New variable.
> > * gnu/packages/patches/libarchive-remove-potential-backdoor.patch: New file.
> > * gnu/local.mk (dist_patch_DATA): Add it.
> >
>
> Overall changes look good, but I have not had a chance to try it locally
> (building or dependents).
>

This looks like what I was going to suggest

Toggle quote (18 lines)
> [...]
>
> > +(define-public libarchive/fixed
> > + (package
> > + (inherit libarchive)
> > + (version "3.6.1")
> > + (source
> > + (origin
> > + (method url-fetch)
> > + (uri (list (string-append "https://libarchive.org/downloads/libarchive-"
> > + version ".tar.xz")
> > + (string-append "https://github.com/libarchive/libarchive"
> > + "/releases/download/v" version "/libarchive-"
> > + version ".tar.xz")))
>
> In light of the xz backdoor, perhaps we should just do a git checkout of
> the v3.6.1 tag rather than the tarballs? Assuming that works, of course.

In this case it was just the patch which didn't do (just) what the
commit message said. IMO applying this patch will make us safe from this
potential JiaT75 backdoor, no bootstrapping from source needed.

Toggle quote (9 lines)
> I haven't had a chance to look at potential ABI changes, but perhaps at
> least v3.6.2 is graftable? That also lists a security update (as well as
> later versions).
>
> Or, if it is easier and this is tested on your end, let's push this and
> do an upgrade to the latest on a branch. I would volunteer mesa-updates,
> but Cuirass has been stuck all day not building anything, so I don't
> know what will end up being quickest (which branch or a new one).

If it turns out that we need to move forward a bit to guard against
other CVEs then this patch should be forward compatible, considering it
was just added to the libarchive repository.

Toggle quote (3 lines)
> Thanks for the quick work!
> John

Indeed. Thanks!

--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmYMBvQACgkQQarn3Mo9
g1HyLg//TPAkGSR0VWtg1lqvIEuXZ1+mB2S+BKd1LBIAy62S8brhfLVSkC/o23Li
4ogrMWlrLFrLeTIC8U9PX+//FBOpTh8UgNUqcATNGoozhK9nRgkTtddg+ClGkSyb
CEaZy4iVyfGHlJ9DwiTR4moz89XxA2Ax1c01MR38rgRi3keprPgHhXWguKBnGXPW
3hyln4Q9xqzKeRbiAUF0a8SJEzJFHF/CjA3556dLuK6pNqvqd1L7fv+efZMDaPVp
LHpg3gTKMhl14vl/GwFwzO9EJcMZv4ltjjMLonHHvea8ZnhmRvWZb5Jf72hdG8QZ
F2vYUGtVFXN0V/o8sALraI6MFcJff2Plm0BAqm8Kuqo78wBfhN/wAOe43K36uhCO
7hiqSoifrziItHnbHxRNhtHcTLIzh9v9yhjbZBL3atZiwo5MHMsRbw7a+/XwxSZ6
+aVaiP59RDXrampRQEbJMYtE++titfMRDvhQUH3cUYwf47lUDpKNhHGONHFW7V7e
cPRsOSqmAShcCSWjlzF95gOwhlt2eUGv5GZq7isLNuHz1f7KZeHpF3LIGAhvmvC7
dwiFBIGXXmx5vkTFHXqbEHH+ZuqzmaDSTLI6pHwZbABAQBBjkLrN9fAr9wtzcbte
Gmf0zvCgAJJ7hgCCNGLtVhw2lbofPIGj0eRYcGNDEJDEAJ7R/3c=
=+yka
-----END PGP SIGNATURE-----


P
P
pelzflorian (Florian Pelz) wrote on 2 Apr 15:45 +0200
(name . John Kehayias)(address . john.kehayias@protonmail.com)
871q7nev3k.fsf@pelzflorian.de
Hello,

John Kehayias via Guix-patches via <guix-patches@gnu.org> writes:
Toggle quote (16 lines)
>> +(define-public libarchive/fixed
>> + (package
>> + (inherit libarchive)
>> + (version "3.6.1")
>> + (source
>> + (origin
>> + (method url-fetch)
>> + (uri (list (string-append "https://libarchive.org/downloads/libarchive-"
>> + version ".tar.xz")
>> + (string-append "https://github.com/libarchive/libarchive"
>> + "/releases/download/v" version "/libarchive-"
>> + version ".tar.xz")))
>
> In light of the xz backdoor, perhaps we should just do a git checkout of
> the v3.6.1 tag rather than the tarballs? Assuming that works, of course.

Not having followed the details, I believe the git checkout contained an
incomplete part of the malicious code too, from what Joshua Branson (I
guess the sender is him?) cites from Phoronix

jbranso@dismail.de writes:
Toggle quote (7 lines)
> The malicious injection present in the xz versions 5.6.0 and 5.6.1
> libraries is obfuscated and only included in full in the download package
> - the Git distribution lacks the M4 macro that triggers the build
> of the malicious code. The second-stage artifacts are present in
> the Git repository for the injection during the build time, in
> case the malicious M4 macro is present.

It doesn’t look like avoiding tarballs gives us more verified code.

Regards,
Florian
L
L
Leo Famulari wrote on 4 Apr 00:08 +0200
(name . John Kehayias)(address . john.kehayias@protonmail.com)
Zg3TTEwIZkIObXc0@jasmine.lan
On Tue, Apr 02, 2024 at 03:23:44AM +0000, John Kehayias wrote:
Toggle quote (3 lines)
> Overall changes look good, but I have not had a chance to try it locally
> (building or dependents).

I successfully tested with the file-roller package, which depends
directly on libarchive and no other related packages. I think it's a
reasonable basic test case.

I agree it's a good idea to look into a more comprehensive update to
libarchive, but I just wanted to get this patch in ASAP.

Pushed as 629614c7a3f9283306939402f1ff46914f327c21
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEaEByLu7k06ZO5T6saqwZY3V/R/8FAmYN00wACgkQaqwZY3V/
R/8IqhAAre19kcT27tbQVcEhFNhsBFRmtAf6FZ+Vnr8Z9yx7X4yYkr10l0Q9yzta
aU5p5IMr5QjK8N3g0o2tZbBoTZybDtbhL7ra8C4K6JBnn623yJIbbi46jJoMKz8V
H+1IYMPtpr/CU4pxZiK+4LQS9poXlNiFnUxKOs4OQUylZRQvrz/ifnbfCRmHGWoZ
xt116HTrxfb70jwtWptzIEJwpSTXWDaOidDygCihH38YbOG20zRDFrEdea3ciAiZ
4rink768fYZSjBeAWcbFA92QAgbrmI4lO8mfLi1y1uwTdkqV9b2zk7Eh2BOalE12
txJCHD5JG01nnooquFZjCaEbwKf4JPZV2Y7kb9UXRa63x/0u0RtDP3AznABjcRD3
vgvdcmwr41FPiSgKI/Cm4U8RBwLRebKNGMoz9rHzr5xXv5ana/54VPugQZNmEqYx
ZS5HOtjuB9OdZ/C6t53QIDnwLFts5OVwCq3EPiXebU6hfffVKpCDPFyeDPMPEz0I
rgS3i58qM8x3XMJ2teuDZy+YUBQ2aCg7IK9xBp4I/iXj8Fu+AFSHAg08W7bfPO4m
qaV0SiJZQRrV61harg7nM7Z02VxIJI0CeQZBQQhmFbG2hNcbIS+21vJk74cqYowg
AYWGuD9Kf3f0CFdLtQgWHBR1l4g4h6KAE3Gxdkm354wUtcQijjo=
=h8Y8
-----END PGP SIGNATURE-----


Closed
J
J
John Kehayias wrote on 4 Apr 04:38 +0200
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
8734s1x35x.fsf@protonmail.com
Hello,

On Tue, Apr 02, 2024 at 03:45 PM, pelzflorian (Florian Pelz) wrote:

Toggle quote (35 lines)
> Hello,
>
> John Kehayias via Guix-patches via <guix-patches@gnu.org> writes:
>>> +(define-public libarchive/fixed
>>> + (package
>>> + (inherit libarchive)
>>> + (version "3.6.1")
>>> + (source
>>> + (origin
>>> + (method url-fetch)
>>> + (uri (list (string-append "<https://libarchive.org/downloads/libarchive>-"
>>> + version ".tar.xz")
>>> + (string-append "<https://github.com/libarchive/libarchive>"
>>> + "/releases/download/v" version "/libarchive-"
>>> + version ".tar.xz")))
>>
>> In light of the xz backdoor, perhaps we should just do a git checkout of
>> the v3.6.1 tag rather than the tarballs? Assuming that works, of course.
>
> Not having followed the details, I believe the git checkout contained an
> incomplete part of the malicious code too, from what Joshua Branson (I
> guess the sender is him?) cites from Phoronix
> <https://lists.gnu.org/archive/html/guix-devel/2024-04/msg00002.html>:
>
> jbranso@dismail.de writes:
>> The malicious injection present in the xz versions 5.6.0 and 5.6.1
>> libraries is obfuscated and only included in full in the download package
>> - the Git distribution lacks the M4 macro that triggers the build
>> of the malicious code. The second-stage artifacts are present in
>> the Git repository for the injection during the build time, in
>> case the malicious M4 macro is present.
>
> It doesn’t look like avoiding tarballs gives us more verified code.
>

Well, it removes one step where something can be added. From what I
understand release tarballs don't match a git checkout as often build
artifacts (from autotools) are added, so it is just another potential
attack vector. Indeed, it was only part of the attack here, but I do
believe there is general support for trying to favor git checkouts
when we can (there is overhead and I think issues for parts in
bootstrapping, to get git). Certainly not perfect, but gets us to
"just" the source. One can still do things with access of course.

Thanks Leo for the quick work here and pushing the patch, much
appreciated!

John
L
L
Ludovic Courtès wrote on 7 Apr 22:41 +0200
control message for bug #70114
(address . control@debbugs.gnu.org)
87ttkcoqhs.fsf@gnu.org
tags 70114 + security
quit
?
Your comment

This issue is archived.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 70113
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