xz/liblzma has been compromised

201 views
Skip to first unread message

Dima Pasechnik

unread,
Mar 29, 2024, 3:18:24 PM3/29/24
to sage-devel, sage-support, sage-release
https://www.openwall.com/lists/oss-security/2024/03/29/4

if your have xz 5.6.0 or 5.6.1 installed (e.g. Debian testing/unstable)
you have a backdoored xz.

Dima Pasechnik

unread,
Mar 29, 2024, 3:36:30 PM3/29/24
to sage-devel, sage-support, sage-release, Isuru Fernando
aand Conda: https://anaconda.org/anaconda/xz shows version 5.6.1

Matthias Koeppe

unread,
Mar 29, 2024, 3:39:01 PM3/29/24
to sage-devel
Workaround with the Sage distribution: "./configure --without-system-liblzma --without-system-xz"
(Our xz package dates back from before the attackers were born;)

Incidentally, the cryptographic protection of the Sage distribution is wildly insufficient.
I've opened https://github.com/sagemath/sage/issues/37691 for this -- any takers?

Dima Pasechnik

unread,
Mar 29, 2024, 3:42:29 PM3/29/24
to sage-...@googlegroups.com
On Fri, Mar 29, 2024 at 7:39 PM Matthias Koeppe
<matthia...@gmail.com> wrote:
>
> Workaround with the Sage distribution: "./configure --without-system-liblzma --without-system-xz"
> (Our xz package dates back from before the attackers were born;)
>
> Incidentally, the cryptographic protection of the Sage distribution is wildly insufficient.
> I've opened https://github.com/sagemath/sage/issues/37691 for this -- any takers?

I'd switch to sha256.
And require PGP-signed commits, etc.

well, I can't even comment on that issue :-)


>
>
> On Friday, March 29, 2024 at 12:18:24 PM UTC-7 Dima Pasechnik wrote:
>>
>> https://www.openwall.com/lists/oss-security/2024/03/29/4
>>
>> if your have xz 5.6.0 or 5.6.1 installed (e.g. Debian testing/unstable)
>> you have a backdoored xz.
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/d75e7cc9-9743-4c20-b502-431d400dc5f2n%40googlegroups.com.

Dima Pasechnik

unread,
Mar 29, 2024, 3:45:31 PM3/29/24
to sage-devel, sage-support, sage-release, Isuru Fernando
and Homebrew.
Please upgrade your Homebrew. It should do a downgrade:

`brew upgrade` now "upgrades" xz from 5.6.1 -> 5.4.6

Dima Pasechnik

unread,
Mar 30, 2024, 8:35:20 AM3/30/24
to sage-...@googlegroups.com
On Fri, Mar 29, 2024 at 7:42 PM Dima Pasechnik <dim...@gmail.com> wrote:
>
> On Fri, Mar 29, 2024 at 7:39 PM Matthias Koeppe
> <matthia...@gmail.com> wrote:
> >
> > Workaround with the Sage distribution: "./configure --without-system-liblzma --without-system-xz"
> > (Our xz package dates back from before the attackers were born;)
> >
> > Incidentally, the cryptographic protection of the Sage distribution is wildly insufficient.
> > I've opened https://github.com/sagemath/sage/issues/37691 for this -- any takers?
>
> I'd switch to sha256.
> And require PGP-signed commits, etc.
>
> well, I can't even comment on that issue :-)

By the way, the essential part of xz backdoor was sneaked in as a
modified copy of a gnulib m4 macros file.
As this is "the" way to use gnulib - just vendor what they provide in
your source code - one may wonder again
about the virtues of vendoring a lot of code.
Potentially, any tarfile we host may contain an exploit.

As well as anything produced on CI, VM, or, real, hosts running
compromised OS (latest unstable versions of Debian and Fedora were
compromised with this xz hack, Homebrew was, as well). So this is
something to review urgently, too.

Dima

Marc Culler

unread,
Mar 30, 2024, 10:08:45 AM3/30/24
to sage-devel
> Potentially, any tarfile we host may contain an exploit.

Potentially, any file may contain an exploit.

This hack specifically targeted ssh.  When used by ssh to verify keys, the hacked liblzma would validate certain invalid keys, allowing a "back door" for a particular bad actor to login to the system.

I don't think that the Sage liblzma  could ever end up being the one used by ssh.

We all know how many things are justified as being "for your security" when in fact they do nothing to increase anyone's security and are really just advancing someone's private agenda.

- Marc

Marc Culler

unread,
Mar 30, 2024, 10:30:39 AM3/30/24
to sage-devel
According to  Hacker News:
> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma.

So this hack was not targeting ssh in general, just ssh on certain linux distros.

I would NOT suggest that "for your security" Sage should stop supporting linux.

- Marc

Michael Orlitzky

unread,
Mar 30, 2024, 10:34:37 AM3/30/24
to sage-...@googlegroups.com
On 2024-03-30 07:08:45, Marc Culler wrote:
> > Potentially, any tarfile we host may contain an exploit.
>
> Potentially, any file may contain an exploit.
>
> This hack specifically targeted ssh. When used by ssh to verify keys, the
> hacked liblzma would validate certain invalid keys, allowing a "back door"
> for a particular bad actor to login to the system.

The backdoor that was _found_ targeted SSH. The person who put it
there had commit access to the project for a long time.

I've seen many people assume that if they aren't running a patched
sshd, then they're safe by downgrading to an earlier version free of
the sshd hack. If your earlier version was maintained by the same
malicious person, I wouldn't be so sure. This was a coordinated attack
starting in 2021 or earlier.

None of that invalidates your point of course: bundling (or not) is
irrelevant if the person writing your code is untrusted. On the other
hand, this wouldn't be "our code" if we didn't run our own distro.

Georgi Guninski

unread,
Apr 2, 2024, 11:00:01 AM4/2/24
to sage-...@googlegroups.com
The Register journo analysis of the SNAFU:
https://www.theregister.com/2024/04/01/xz_backdoor_open_source/
Reply all
Reply to author
Forward
0 new messages