Re: Heads up: Backdoor in upstream xz tarball, stable version of IPFire likely unaffected, testing version somewhat affected

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 3621 bytes --]

Hello,

> On 29 Mar 2024, at 21:53, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello *,
> 
> a quick heads-up on reports on the oss-security mailing list that indicate the upstream
> tarball of xz containing a backdoor since version 5.6.0, with the target objective appearing
> to constitute in backdooring SSH: https://openwall.com/lists/oss-security/2024/03/29/4
> 
> Please note that this is a developing situation, so take the assessments below with a
> pinch of salt.
> 
> - The latest stable version of IPFire, IPFire 2.29 - Core Update 184, is NOT affected by
>  the backdoor discussed in the oss-security post linked above. This is because it includes
>  xz 5.4.6 (as mentioned in https://www.ipfire.org/blog/ipfire-2-29-core-update-184-released).
>  Further, since IPFire does NOT patch OpenSSH in order to include lzma compression (which
>  is a requirement for the unveiled backdoor to work), my understanding at this time is that
>  OpenSSH on stable IPFire installations is not affected.

I agree with this assessment.

I believe that IPFire does not meat a number of criteria that are required for this backdoor to be usage:

* The build is checking whether a Debian/RPM package is being built and only then injects the backdoor code. This should not be the case on IPFire and therefore I believe that we don’t even include the malicious code paths.

* OpenSSH is not directly linked against liblzma and we do not have anything else (e.g. that pulls it in). So the library is not loaded into sshd at runtime, so even if liblzma was affected on IPFire, we should not have a compromised SSH service.

>  This is further corroborated by the backdoor known so far only becoming active under
>  certain build environment conditions that are not met by IPFire 2.x's build environment.
> 
>  However, it currently appears as if the xz developer has actively worked towards including
>  a backdoor, rather than their account having been compromised. Therefore, it may be that
>  there are other backdoors in the xz upstream tarball, and that they have been included in
>  earlier versions.
> 
> - Forthcoming Core Update 185 includes two patches that update xz to 5.6.0 and 5.6.1,
>  respectively. These versions are known to include the aforementioned OpenSSH backdoor.
>  The IPFire development team will discuss reversion of xz to a version not known to be
>  affected thus far in the next few days. Currently, both Debian and Fedora opted to
>  revert back to version 5.4.5, rather than 5.4.6 (which is what IPFire currently ships
>  in stable Core Update 184, but is not known to include any malicious code, which only
>  commenced in version 5.6.0).

Adolf has been really quick in providing a patch to downgrade back to 5.4.5. As far as I can see this is what Debian is doing and believing that they have some more information about everything I would like to follow their decisions. I have currently no reason to believe that 5.4.6 is compromised.

The patch has been merged and I have included everything that is linked against XZ in the updater as a precaution.

>  Again, since no custom patching of OpenSSH is in place, the unveiled SSH backdoor would
>  not have been functional on IPFire installations.
> 
> IPFire is currently unaware of the unveiled backdoor impacting any other service that is
> usually directly exposed on IPFire installations to the internet, such as OpenVPN or IPsec.
> 
> For reference, CVE-2024-3094 has been assigned by Red Hat for this issue.
> 
> Thanks, and best regards,
> Peter Müller

-Michael