[package] xz_utils/5.6.0: contains malicious code (CVE-2024-3094)

[fschoenm]

Description

Not sure how this is handled, I didn't find any information in the documentation But here's the CVE about malicious code in xz_utils 5.6.0+: https://nvd.nist.gov/vuln/detail/CVE-2024-3094

Maybe you want to remove the affected packages for now.

Package and Environment Details

• Package Name/Version: xz_utils/5.6.0 and xz_utils/5.6.1

Conan profile

[settings]
os=Macos
os_build=Macos
arch=armv8
arch_build=armv8
compiler=apple-clang
compiler.version=14
compiler.libcxx=libc++
build_type=Release
[options]
[conf]
[build_requires]
[env]

Steps to reproduce

n/a

Logs

Click to expand log

Put your log output here

[jwillikers]

I just found out. We use the compromised release archive.

[jwillikers]

Attention @uilianries @RubenRBS @jcar87 @franramirez688 @memsharded This CVE appears to be intentional from the author. We should immediately downgrade any dependencies using xz_utils 5.6.x ASAP.

[vielmetti]

CVE-2024-3094 links to the internal Github advisory, for reference.

[Nekto89]

In description I see "configure". Does it also affect CMake builds?

[franramirez688]

Attention @uilianries @RubenRBS @jcar87 @franramirez688 @memsharded This CVE appears to be intentional from the author. We should immediately downgrade any dependencies using xz_utils 5.6.x ASAP.

Thank everyone for the super fast heads-up and the PRs to mitigate the issue 👏 Much appreciated the rapid reaction🥇
We are working on removing also all the remaining binaries.
Thanks again!

[danimtb]

Update: Recipe revisions and packages for xz_utils versions 5.6.0 and 5.6.1 have been removed from conan center and they are no longer listed in the conan client and cannot be installed.

[danimtb]

xz_utils 5.6.0 and 5.6.1 recipe versions have been removed from conan-center-index:

• xz_utils/5.6.x: Remove compromised versions CVE-2024-3094 #23311

Recipes depending on the xz_utils affected versions have been downgraded:

• cpython: Downgrade xz_utils to mitigate CVE-2024-3094 #23313
• libunwind: Downgrade xz_utils to mitigate CVE-2024-3094 #23312

[jwillikers]

In description I see "configure". Does it also affect CMake builds?

@Nekto89 I'm pretty sure that only a very small subset of package managers use CMake to build xz_utils. I only know of us and vcpkg. So it probably hasn't received as much attention. I'm not sure if the CMake build system was also modified like the Autotools one to inject the malicious code. I imagine we'll learn more in the upcoming weeks.

[jcar87]

Hi @fschoenm and @jwillikers - thank you for reporting this and for being involved in the quick fixes.
Thank you as well to the Conan team members for the fast reaction.

Based on the currently known details of the discovered backdoor, we currently do not believe the recipe and binaries provided by Conan Center were affected (see below for details). However, there appears to be malicious intent in recent contributions in the upstream source code of xzutils. Due to how exceptional this is, we have taken the following steps:

• Recipe revisions for all 5.6.0 and 5.6.1 versions of the recipe have been removed from the Conan Center remote. Our servers will no longer provide these. This includes not only the binary packages, but the recipes as well (so versions 5.6.x are no longer available)
• The only two recipes in Conan Center that depended on the affected versions of xz_utils are cpython and libunwind - new revisions have been published to revert these to require the older known versions.

Still pending:

• We are in the process of identifying the affected recipe revisions of cpython and libunwind to remove them from the remote as well.

Advise for all users that fetch dependencies directly from Conan Center

• Run conan remove "xz_utils/5.6*" to remove any copy of these versions in the local Conan Cache.
• Use --update when resolving a graph against the Conan Center remote (with conan install, or conan graph info)
• If using lockfiles, please inspect the file to ensure there is no version lock for xz_utils to any 5.6.x version
• When running conan install or equivalent, please ensure that if zx_utils is present, that the version is not 5.6.0 or 5.6.1.

Please note that at this stage, it is unclear whether the recipe or the binaries provided by Conan Center were affected. A preliminary analysis based on the specific described in the following links:

• https://www.openwall.com/lists/oss-security/2024/03/29/4
• https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

would indicate that our binaries were not affected. While we currently believe our recipe and binaries were not affected by the mechanisms described above, it appears there may have been a malicious actor contributing upstream and the extent of the malicious code is unknown, so we have taken the steps mentioned as an abundance of caution.

The recipe in Conan Center for versions 5.6.0 and 5.6.1

• Used the CMake scripts, whereas the mechanisms described above used the autotools (./configure) - however a lot is still unknown at this stage and the CMake scripts would need to be analyised and verified as well, as the situation develops.
• The code injection appears to detect when the sources are being built driven by the debian and RPM build mechanisms - which is not the case for Conan Center recipes.

On the other hand, Conan recipes are NOT installed at the system level, and they are not installed in locations that are discoverable by system applications - thus, on the affected systems, a vulnerable version of this library existing in the Conan cache would not affect system services such as sshd. However, a Conan that is operating on a Conan conanrun.sh or a Conan-generated VirtualRunEnv, may be exposing applications to the malicious library if the shared variant was installed. It is currently unknown whether the malicious code targeted anything other than sshd.

The situation is still developing and we will provide updates as more is discovered.
We encourage users and system maintainers to check https://nvd.nist.gov/vuln/detail/CVE-2024-3094 and act accordingly.

[mmomtchev]

Now I have:

xz_utils/5.4.5: Sources downloaded from 'conancenter'
xz_utils/5.4.5: Calling source() in /home/runner/.conan2/p/xz_ute033bfcacc0c2/s/src
ERROR: xz_utils/5.4.5: Error in source() method, line 77
	get(self, **self.conan_data["sources"][self.version], strip_root=True)
	ConanException: sha256 signature failed for 'xz-5.4.5.tar.xz' file. 
 Provided signature: da9dec6c12cf2ecf269c31ab65b5de18e8e52b96f35d5bcd08c12b43e6878803  
 Computed signature: fc1b5fbae8dfeaec62d9e80509e0151dc1ead6fa5119911f294d701660a99f38

on a clean conan 2.3.0-git install in GHA with:

self.requires('libtiff/[>=4.6.0 <4.7.0]')
self.requires('sqlite3/[>=3.45.0 <3.46.0]')
self.tool_requires('pkgconf/2.1.0')
self.tool_requires('sqlite3/[>=3.45.0]')

[jcar87]

Hi @mmomtchev - thank you for reporting this.

As reported in https://tukaani.org/xz-backdoor/, it appears that the sources, even for older versions, pointed to GitHub, which has now disabled the repository and thus those links are no longer accessible. We need to locate a viable mirror - however we will only update the recipe to point to a new one if we have complete confidence.

Appreciate this is a tough call on GitHub's end as well

[jwillikers]

The official Git source can be found at https://git.tukaani.org/. The primary author of the repository has made a post here on the website, too. For release tarballs, might be worth looking into using https://sourceforge.net/projects/lzmautils/files/. Appears that the original maintainer created the repository. Ideally, the checksums of the tarballs from there match the ones we already have.

[puetzk]

In description I see "configure". Does it also affect CMake builds?

Seems not the same one, but there seems to have been sabotage to the CMake check for enabling the landlock sandbox in Linux >= 5.13. See https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00;hp=af071ef7702debef4f1d324616a0137a5001c14c

Which certainly smells of there being some other yet-to-be-found vulnerability buried inside they were expecting to exploit... if not, sabotaging ENABLE_SANDBOX wouldn't have much payoff.

[valgur]

As a takeaway from this fiasco, I would recommend two policy changes on CCI going forward:

1. Require the use of source archives produced directly from git tag snapshots, if possible. It's too easy to slip in additional changes to the custom source archives undetected. We are currently recommending to use the custom archives to protect against the occasional instability in the automatically generated archives due to unrelated changes by GitHub, etc. However, this is not the only way to protect against this. We could instead (a) keep an archive of all linked sources that could be used to verify that the actual contents are unchanged, (b) keep track of the git commit hash corresponding to the git tag as it must stay unchanged in any case.
2. Prohibit the use of ./configure without running autoreconf first. The configure.ac files are difficult to audit, but the included configure files are practically impossible to check and are a prime vector for malicious changes.

[Ahajha]

Just chiming in, as the one who made the 5.6.0 PR here (oddly, I feel bad about it, despite me personally doing nothing wrong), I think them dropping the Visual Studio build is what (at least hopefully) saved our packages from being vulnerable, as if they hadn't I wouldn't have switched the recipe to use CMake.

[jwillikers]

Just chiming in, as the one who made the 5.6.0 PR here (oddly, I feel bad about it, despite me personally doing nothing wrong), I think them dropping the Visual Studio build is what (at least hopefully) saved our packages from being vulnerable, as if they hadn't I wouldn't have switched the recipe to use CMake.

@Ahajha I meant reach out to you since I reverted your PR that added 5.6.x. I really appreciate you putting in the extra work to migrate us from Autotools to CMake when you added that and hope after this mess is sorted out we can make use of that work again. I really didn't like reverting something that moved a package away from using Autotools.

[RubenRBS]

(oddly, I feel bad about it, despite me personally doing nothing wrong)

@Ahajha absolutely no fault on you, no worries! This flew under everybody's radar :)

I just wanted to join Jordan in thanking you for your efforts either way, they really are appreciated

[Ahajha]

Thanks, both of you :) It's not really a "guilt" feeling, but more of like a "huh, in a weird way I was involved in this". I'm periodically checking if there are any updates to the situation.

[LarrxX]

Now I have:

xz_utils/5.4.5: Sources downloaded from 'conancenter'
xz_utils/5.4.5: Calling source() in /home/runner/.conan2/p/xz_ute033bfcacc0c2/s/src
ERROR: xz_utils/5.4.5: Error in source() method, line 77
	get(self, **self.conan_data["sources"][self.version], strip_root=True)
	ConanException: sha256 signature failed for 'xz-5.4.5.tar.xz' file. 
 Provided signature: da9dec6c12cf2ecf269c31ab65b5de18e8e52b96f35d5bcd08c12b43e6878803  
 Computed signature: fc1b5fbae8dfeaec62d9e80509e0151dc1ead6fa5119911f294d701660a99f38

I am getting the same error, but then conan proceeds to build again from source (since I gave it the --build=missing flag). Is that safe? Or should I watch this thread and wait for the issue to be resolved?

[Edited for typos]

[uilianries]

@LarrxX Hello, please, take a look in the comment: #23329 (comment)

[LarrxX]

Great, thanks to all conan ppl for their quick reaction. Much love <3

[jcar87]

Which certainly smells of there being some other yet-to-be-found vulnerability buried inside they were expecting to exploit... if not, sabotaging ENABLE_SANDBOX wouldn't have much payoff.

Hi @puetzk - thanks for pointing this out.

It looks like this affects the auto-detection of the sandbox for the executable utilities. Given that this relies on specific kernel headers present on the system, for binaries built by Conan Center it's unlikely we have headers for this version of the kernel (the Linux docker images are based on an older distro to ensure maximum glibc compatibility) - so I'm fairly certain that check would evaluate to false either way on our CI, even without the spurious . (as per https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00;hp=af071ef7702debef4f1d324616a0137a5001c14c). It's still worth noting that removing these affected versions was the right action - given the uncertainty.

On the other hand, and as echoed by the CMake maintainers here - this kind of build-time autodetection is an anti-pattern that we try to avoid in Conan Center index. In this case, should be an option and this either on or off, and requested by the consumer of the recipe - without leaving room for a guess.

[jcar87]

Closing this issue as the affected versions were swiftly removed, and any other recipes explicitly depending on 5.6.x have been fixed. Additionally and as an exception, we have added our own mirrors for the tarballs for older releases when building these from source (see here).