There is currently an ongoing discussion on various platforms about a security issue in xz/liblzma, and here is what we know at this time. This post serves as a way to inform the community about our assessment of the impact on nixpkgs.
Summary
It was discovered that xz from version 5.6.0 started shipping malicious code that would only be executed through its release tarballs. A malicious code path would be executed when running configure and modify the resulting liblzma library.
Impact
NixOS 23.11 is unaffected since it ships with xz 5.4.4.
NixOS Unstable currently ships with xz 5.6.1 but is unaffected, since the malicious code path exits early, and liblzma remains unpatched.
Workaround
none
Resolution
The security team and other stakeholders agreed that downgrading xz to 5.4.6 for NixOS Unstable was the safest choice for now. The downgrade needs to pass through staging-next, which will likely require another 10 days.
For those that waiting for the downgrade is not within their risk tolerance, another option would be to rollback your nix stuff to the last nixpkgs revision before 5.6.0 / 5.6.1 versions
That can be checked on the following links:
- https://hydra.nixos.org/job/nixpkgs/trunk/xz.x86_64-linux (nixpkgs), and
- https://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.xz.x86_64-linux (NixOS)
Last evals before xz 5.6.x are
- Nixpkgs: https://hydra.nixos.org/build/250936654 (input nixpks revision `9a9dae8f6319600fa9aebde37f340975cab4b8c0`)
- NixOS: https://hydra.nixos.org/build/250820195 (input nixpkgs revision `73de017ef2d18a04ac4bfd0c02650007ccb31c2a`)
Disclaimer: Those are 1 month old and depending on the circumstances rolling back to such a version might be worse. Your mileage may vary.
A good part of packages have been built on the staging-next branch after the xz downgrade; it has the following rev: d6dc19adbda4fd92fe9a332327a8113eaa843894 ( from https://hydra.nixos.org/eval/1805322#tabs-inputs )
This is currently at the head of the queue, but since xz causes a stdenv rebuild on all four supported platforms, we are talking about a 220,000 packages in the queue that need to be built.
Note that the malicious code is in the test artifacts, the known execution vector currently only has been found in the bespoke tarballs they publish from their website.
I think that’s not the case, the ones generated by github are not affected (the Source ones), the release artifacts published on the release page are affected and it looks like it’s what nixpkgs is using. Their website just links to github releases.
When I look at XZ Utils the tarballs linked from there are from Github. My understanding from the writeup on xz-utils backdoor situation · GitHub is that the tarball contents do not correspond to the Github git repository contents.
To what degree was nixpkgs affected by this? My understanding is that the backdoor was only injected to rpm and deb builds, which nixpkgs doesn’t use. Is that merely conjecture at the moment?
The issue can only be triggered when using the official release tarball because it requires a change to a Makefile that is not present in the Git repository.
To the current knowledge of the community for packages using the xz nixpkgs package:
even with the backdoored tarball the script injecting the backdoor does not work in our build context. Basically the script injecting the backdoor runs but it exits without doing anything because the required conditions do not match: the backdoor is not injected in the built binaries
the backdoor itself has a certain number of conditions that are not met in a NixOS environment and as such is not effective
Note that the situation is evolving and more knowledge is being acquired thanks to people looking more closely to the backdoor itself but if you rollback to a nixpkgs unstable pin from before the upgrade to xz 5.6.x you need to consider, according to your threat model, that other security issues have been fixed in the meantime.
Note: the same guy also made some suspicious “contributions” to libarchive:
I would git revert every single one of these, just in case.
I checked their entire github log and, fortunately, it looks like only libarchive and xz are affected.
There’s not much we can do, it’s a downside of how Nix handles package dependencies. You can’t simply swap out one core package without rebuilding everything that depends on it, otherwise the resulting packages won’t pure.
If you’re on NixOS you can use system.replaceRuntimeDependencies to rewrite all the references to the infected xz, until the revert commit reaches the unstable channel.