From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka 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: Sat, 30 Mar 2024 14:30:05 +0100 Message-ID: <2f081408-1c30-4e37-80d1-e9a3feb0dc68@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7616581168417291131==" List-Id: --===============7616581168417291131== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi All, The xz github repository has been disabled by github. Therefore effectively xz will now stay at version 5.4.x Likely that any new xz repository that gets set up to do future bug and=20 security fixes is going to be looked at suspiciously from now on,=20 assuming they can get a repo accepted. Therefore I am wondering if we need to put into process a plan to change=20 all packages that currently use xz archiving in the lfs etc to use gz or=20 bz2. When that is completed, if xz is not used for anything else within=20 IPFire other than archiving/de-archiving files, then we could remove xz=20 completely. I am just thinking that if we don't do this then if a security bug is=20 discovered in xz (not from deliberate implementation but just a=20 historical bug) there won't be anyone updating xz to fix it and even if=20 they did would people use it? Is this a reasonable thought or am I being to paranoid. Regards, Adolf. On 30/03/2024 13:37, Michael Tremer wrote: > Hello, > >> On 29 Mar 2024, at 21:53, Peter M=C3=BCller w= rote: >> >> 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 o= bjective 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 b= elow with a >> pinch of salt. >> >> - The latest stable version of IPFire, IPFire 2.29 - Core Update 184, is N= OT affected by >> the backdoor discussed in the oss-security post linked above. This is be= cause it includes >> xz 5.4.6 (as mentioned in https://www.ipfire.org/blog/ipfire-2-29-core-u= pdate-184-released). >> Further, since IPFire does NOT patch OpenSSH in order to include lzma co= mpression (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 onl= y then injects the backdoor code. This should not be the case on IPFire and t= herefore I believe that we don=E2=80=99t even include the malicious code path= s. > > * OpenSSH is not directly linked against liblzma and we do not have anythin= g else (e.g. that pulls it in). So the library is not loaded into sshd at run= time, so even if liblzma was affected on IPFire, we should not have a comprom= ised 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 bu= ild 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 Ope= nSSH backdoor. >> The IPFire development team will discuss reversion of xz to a version no= t known to be >> affected thus far in the next few days. Currently, both Debian and Fedor= a opted to >> revert back to version 5.4.5, rather than 5.4.6 (which is what IPFire cu= rrently ships >> in stable Core Update 184, but is not known to include any malicious cod= e, 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 ha= ve some more information about everything I would like to follow their decisi= ons. 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 aga= inst 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 s= ervice 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=C3=BCller > -Michael --=20 Sent from my laptop --===============7616581168417291131==--