Re: Backdoor in upstream xz-utils

[John Kehayias]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


-----BEGIN PGP SIGNATURE-----

iQJRBAEBCgA7FiEEpCB7VsJVEJ8ssxV+SZCXrl6oFdkFAmYHK0sdHGpvaG4ua2Vo
YXlpYXNAcHJvdG9ubWFpbC5jb20ACgkQSZCXrl6oFdkFRA//WaJMegtHd88wlq0V
QovAYD7+d6zj5DxgVTiGKXckyKWx7AceVJ0WVp9MB+WxU8dEXepEnd9AHOA4v/Fb
HLy4prms+noIpXqHW5y6EDgbMiBUX2rk6UVq7qnLCPujfv3hrJl4S7B5fJxjLSM/
M++F40YKc6PNSjQHi9BH5+Vl70jGCIzXNcomvEanu4SAsXLSlEwvOlnAPD57mb4k
n4Tg4d7ExXjdi7/qdq/OnF2RGQjiLQ4qX7AeSu8kIaEaK3WdMy1JO1fy9vaZNuSg
oCuUGJYCFj60BEYDQdUM8NiNe76zVzXvP/wKrR1XpqsnK9keKKEZpuZCQmJApgCJ
dvVbrU8OfKPJ/B7CwNJu32FyrdgQt53ytYjNxs/cNNjB2ciDeIGszCzxwytRZz4k
JEbE8VZrUACNvQXCdRbr1Jse1+FuM2hjTwILdia/A8GcWn9tfmfGdqlqOuw6c8qG
hYX7l3+3t0c7VzLhgs2iE/BEKtUAYCrwRf+10J9dOm4TzmbEbg7+1j7FJcYhmIgJ
qeEXistWXx7FY2Yl0UjrNtxi3UGR5rnx2hAb3zEcMoqcHHKuKz/X8aeMfIHryn23
rQms/cVwAPeR908xwbJgqkzQhY5A9DrU+0VGssILyXKvMYp6xTXJ6cf2gGLyhAFF
VerlLVFCEHunNyWr94ZTeXr3p00=
=dUKI
-----END PGP SIGNATURE-----
Hi Ryan, Felix, and guix-devel,

On Fri, Mar 29, 2024 at 01:39 PM, Felix Lechner via Reports of security issues 
in Guix itself and in packages provided by Guix wrote:

> Hi Ryan,
>
> On Fri, Mar 29 2024, Ryan Prior wrote:
>
>> I'm reading today that a backdoor is present in xz's upstream tarball
>> (but not in git), starting at version 5.6.0. Source:
>> <https://www.openwall.com/lists/oss-security/2024/03/29/4>
>
> Thanks for sending this!  This is an extremely serious vulnerability
> with criminal intent.  I cc'd guix-security@gnu.org just in case you
> haven't.
>

At least me (as part of guix-security) is aware and have been reading
the analysis and further investigation.

Both clever and interesting, but also worrisome. I think we were
rather lucky this was found relatively quickly, though it seems to
point to a bad actor and throws into question other projects (like
libarchive) which have contributions from the same identity. Likely
other accounts are involved too, so maybe on a positive side this
unravels other issues.

The discussion on Hacker News has also been informative (though rather
long now): <https://news.ycombinator.com/item?id=39865810>

>> Guix currently packages xz-utils 5.2.8 as "xz" using the upstream
>> tarball. [...] Should we switch from using upstream tarballs to some
>> fork with more responsible maintainers?
>
> Guix's habit of building from tarballs is a poor idea because tarballs
> often differ.  For example, maintainers may choose to ship a ./configure
> script that is otherwise not present in Git (although a configure.ac
> might be).  Guix should build from Git.
>

We discussed a bit on #guix today about this. A movement to sourcing
more directly from Git in general has been discussed before, though
has some hurdles. I will let someone more knowledgeable about the
details chime in, but yes, something we should do.

Unfortunately in this case, while it seems the older versions don't
have *this* exploit, given the perpetrator either is or has control over
a maintainer account, it throws into question a lot more than the most
recent version. We will have to keep a careful eye on this. I'm not
currently aware of anything untoward for our current version, so far.

>> Is there a way we can blacklist known bad versions?
>

I'm not sure what you mean, but I don't think so. The main danger is
in guix time-machine to the past, as you are (purposefully) going to
older versions of software. This is warned in the manual
<https://guix.gnu.org/en/manual/devel/en/html_node/Invoking-guix-time_002dmachine.html>
though we should perhaps do this at runtime as well.

Even better would be if we can warn about known bad versions. Such a
tool was started (guix health) here:
<https://issues.guix.gnu.org/31444> Anyone up for reviving it, now
that we have some changes that should make this more doable (based on
a quick glance of more recent messages)?

> Having said all that, I am not sure Guix is affected.
>
> On my systems, the 'detect.sh' script shows no referece to liblzma in
> sshd.  Everyone, please send additional reports.
>

Pretty sure we are not affected, at least with what is known: the
exploit targets particular systems and things like argv[0] being
/usr/sbin/sshd. A combination perhaps of who or what was being
targeted as well as trying to make this harder to discover.

Still, we should have an abundance of caution and pay close attention,
as there is much we don't know and a history of commits to go through.
As well as being suspicious in general of things like binary files
added to a release tarball (as a project we always try to make sure
there are no binary files anyway), this is a clear example of a
clever/malicious way of causing harm.

Please do feel free to report privately any concerns or potential
affected packages to guix-security@gnu.org as well. And if you are
interested in helping with these things, I'm sure we could rotate in
some people for that team.

Thanks all! An action-packed Friday.

John