From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer 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: Mon, 01 Apr 2024 12:56:19 +0100 Message-ID: <77F5BA0F-C59A-40E4-B9B3-9615F1C6EA12@ipfire.org> In-Reply-To: <2f081408-1c30-4e37-80d1-e9a3feb0dc68@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1327353837067247486==" List-Id: --===============1327353837067247486== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 30 Mar 2024, at 13:30, Adolf Belka wrote: >=20 > Hi All, >=20 > The xz github repository has been disabled by github. >=20 > Therefore effectively xz will now stay at version 5.4.x >=20 > Likely that any new xz repository that gets set up to do future bug and sec= urity fixes is going to be looked at suspiciously from now on, assuming they = can get a repo accepted. >=20 > Therefore I am wondering if we need to put into process a plan to change al= l packages that currently use xz archiving in the lfs etc to use gz or bz2. I had the same thought. But only a thought. I am not entirely sure what would= actually change if we would do this step. I would also like to (re-)consider= if us publishing any archives compressed using XZ is the right way to go now. On the list of pro (XZ): * XZ is widely used * It has a great compression rate * Technically the format has not been compromised, just one implementation of= a compressor/decompressor. The backdoor did not even target the generated or= extracted files which it could have done as well compromising any archived d= ata, deliberately corrupting it=E2=80=A6 I don=E2=80=99t know what bad people= like doing all day. On the cons are: * https://lzip.nongnu.org/xz_inadequate.html - I find these arguments quite c= onvincing, however, other formats have their weaknesses, too. * If we would go back to another well-known format (of which there is only Gz= ip), we would ship way larger files. * If we would go to a format that has similar properties (LZIP or Zstandard),= we face issues with usability because decoders might not be so easily availa= ble. No idea what Windows supports these days. > When that is completed, if xz is not used for anything else within IPFire o= ther than archiving/de-archiving files, then we could remove xz completely. >=20 > I am just thinking that if we don't do this then if a security bug is disco= vered in xz (not from deliberate implementation but just a historical bug) th= ere won't be anyone updating xz to fix it and even if they did would people u= se it? >=20 > Is this a reasonable thought or am I being to paranoid. What is wrong with a bit of healthy paranoia? I think it might be better to b= e more careful when there is no significant overhead in labour for us. So I was going to do the following when updating a package or packaging somet= hing new: * For projects that publish their tarballs compressed using other formats, I = would prefer those over XZ. We don=E2=80=99t *really* care how large the down= loaded source is. A couple of extra bytes don=E2=80=99t hurt. * The order would be still to prefer what compresses better: Zstandard, LZIP,= Gzip. But generally we cannot influence what people use to publish their tarballs a= s. So we will have a large portion of files compressed using XZ and there is = no reason to currently believe that they are compromised through this particu= lar backdoor. We might in the end actually have a lot of people taking the XZ= code apart which should bring us very close to certainty that there is nothi= ng else hidden. Let=E2=80=99s hope we will get this for other formats, too. -Michael > Regards, >=20 > Adolf. >=20 > On 30/03/2024 13:37, Michael Tremer wrote: >> Hello, >>=20 >>> On 29 Mar 2024, at 21:53, Peter M=C3=BCller = wrote: >>>=20 >>> Hello *, >>>=20 >>> a quick heads-up on reports on the oss-security mailing list that indicat= e 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 >>>=20 >>> Please note that this is a developing situation, so take the assessments = below with a >>> pinch of salt. >>>=20 >>> - 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 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. >>=20 >> I believe that IPFire does not meat a number of criteria that are required= for this backdoor to be usage: >>=20 >> * The build is checking whether a Debian/RPM package is being built and on= ly then injects the backdoor code. This should not be the case on IPFire and = therefore I believe that we don=E2=80=99t even include the malicious code pat= hs. >>=20 >> * OpenSSH is not directly linked against liblzma and we do not have anythi= ng else (e.g. that pulls it in). So the library is not loaded into sshd at ru= ntime, so even if liblzma was affected on IPFire, we should not have a compro= mised SSH service. >>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> - 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 h= ave some more information about everything I would like to follow their decis= ions. I have currently no reason to believe that 5.4.6 is compromised. >>=20 >> The patch has been merged and I have included everything that is linked ag= ainst XZ in the updater as a precaution. >>=20 >>> Again, since no custom patching of OpenSSH is in place, the unveiled SSH= backdoor would >>> not have been functional on IPFire installations. >>>=20 >>> 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. >>>=20 >>> For reference, CVE-2024-3094 has been assigned by Red Hat for this issue. >>>=20 >>> Thanks, and best regards, >>> Peter M=C3=BCller >> -Michael >=20 > --=20 > Sent from my laptop >=20 --===============1327353837067247486==--