This is a coordinated disclosure between the Nix, Lix, and Guix projects. Guix is impacted by similar vulnerabilities.
Am I affected?
All systems building untrusted derivations are impacted. Both Linux and Darwin are affected, with Linux systems experiencing a greater impact due to the default-enabled sandbox on them.
Patches
The following versions contain the fixes. Versions older than the listed ones must be considered impacted:
We would like to thank Rory McNamara from the Snyk Security Labs team for reporting these issues with a great level of detail and for providing feedback.
Speaking for the Lix team, Lix 2.90 is vulnerable, it will be removed of unstable.
Lix 2.91 will be deprecated too as part of this unstable run and removed probably later.
25.05 will be the last stable version to have 2.90 & 2.91.
≥ 2.92 will be only supported from now on.
We are not affected by the minVer discussion because Lix is closer to Nix 2.3 (forked after Nix 2.18 for reminders) than any C++ Nix versions in general.
cc @emily who probably have opinions on this topic.
For high-profile security issues like this, is it possible to cherry-pick a fix into nixos-unstable and nixos-25.05? Having to wait for Hydra to finish all the other builds leads to a period where the exploit is known, yet a fix isn’t accessible through the proper channels.
The packages wouldn’t be cached if they were simply cherry-picked, which would require users to build the packages locally - however, telling Hydra to “rush a build” would solve this. I’m not familiar with the internal mechanism of Hydra - but this seems like something that should be possible.
As the Lix blog post recommends it, if you are concerned by getting this ASAP, it’s better to bite the bullet and rebuild it yourself. Lix, for example, is very fast to rebuild.
I’m looking at upgrading from Nix 2.28.2, and it looks like 2.28.4 may have the fix but 2.28.3 does not, as it’s present in nixpkgs from a month ago. The post says 2.28.3 is one of the Fixed versions - is that wrong, or am I misunderstanding something?
Just to understand: Because any user on a system can invoke nix-build (including various machine users such as nginx or postgres or whatever, assuming they are not further locked down with e.g. systemd’s hardening functionality), on arbitrary derivations:
This means escalate to root for any UNIX user on the system?
Is there a nice-and-easy mitigation by somehow defining that just specific users can invoke nix-build (e.g. only root, other named users known to be humans, and, say, my jenkins)?
Because most non-human users on my system have no business invoking nix-build in the first place.
Thank you! It might be worth mentioning allowed-users as a mitigation in the main announcement because people can put immediately in place temporarily without having to wait for rebuilds etc.
That’s a good point, my gut feeling is that this is a dangerous workaround / mitigation, I do not expect most users to recover from a mistake configuration on this side because this involves more arcane knowledge (NIX_REMOTE, using direct access to store, etc.) in case of failures.
We (on the Lix side) definitely planned on very fast paced updates on all relevant channels and we tested quite the QA so we believe this is the safest option. More advanced users can probably do what you are saying but not super comfy offering this workaround because I don’t know what to tell people: allowed-users = root raito ? It all depends on the workload, it feels like… So it’s a bit of “know your workload” situation.
EDIT: a rightful argument by pennae (Lix core team) is that allowed-users does not address the fact that untrusted derivations are built all the time including on non-interactive systems due to the scale of things, so this doesn’t protect you much more if you are very exposed. YMMV.