public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Matthias Fischer <matthias.fischer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Heads up: Backdoor in upstream xz tarball, stable version of IPFire likely unaffected, testing version somewhat affected
Date: Fri, 05 Apr 2024 18:51:47 +0200	[thread overview]
Message-ID: <4cf823b3-3545-420f-9a86-7f2723b163c4@ipfire.org> (raw)
In-Reply-To: <d28081d1-543e-49af-91e5-21045271ff09@ipfire.org>

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

Hi,

Jm2c:

I'm working on an update (httpd 2.5.59) and just saw that the "backdoor
versions" of 'xz 5.6.0/5.6.1' are still available on ipfire.org
(/pub/sources/source-2.x).

Would it not be advisable to delete these versions so that no mischief
can be done with them?

Just m2c...

Best
Matthias

On 29.03.2024 22:53, Peter Müller 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.
> 
>   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).
> 
>   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


  parent reply	other threads:[~2024-04-05 16:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-29 21:53 Peter Müller
2024-03-30 12:37 ` Michael Tremer
2024-03-30 13:30   ` Adolf Belka
2024-04-01 11:56     ` Michael Tremer
2024-04-05 16:51 ` Matthias Fischer [this message]
2024-04-08 16:33   ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4cf823b3-3545-420f-9a86-7f2723b163c4@ipfire.org \
    --to=matthias.fischer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox