SECURITY ADVISORY -- nix >= 2.24 -- Arbitrary NAR injection vulnerability

Announcements
1

Issue

Due to a refactoring released with nix 2.24 arbitrary code can be injected into the nix store by any local (including unprivileged) user or any binary cache.

While nixpkgs pins the stable version of nix to 2.18 (code) the current version of the DeterminateSystems installer is using a vulnerable 2.24 version (code).

As of 2024-09-09 23:50 UTC there is no updated nix version available, but Robert Hensing from the Nix team recommends downgrading to a version older than 2.24.

Nix version 2.24.6 has been released and commited into nixpkgs in PR341049.
As of 2024-09-11 20:00 UTC the updated build has not yet reached the nixos-24.05 channel though. See the Pull Request Tracker

! Note: Lix is not affected by this issue - see their announcement

Workaround

  1. Check your nix version nix --version and downgrade using
    nix.package = pkgs.nixVersions.nix_2_23 where possible.

  2. Should you not be able to downgrade and/ or want to be on the safest side possible, we recommend disabling any extra-substitures in your configuration - unless they are under your direct & exclusive control.
    The Aux Security Team considers the likelyhood of the official NixOS binary cache serving malicious packages to be reasonably low due to the cache being filled by authoritative build servers run by the NixOS project.

  3. Verify all your extra-substituters URLs start with https to prevent MitM (monster-in-the-middle) for binary cache downloads in flight.

  4. Don’t use the DeterminateSystems installer until an update has been provided.

Detailed description
Original: puckipedia@puckipedia.com via Mastodon

if you create a nar file with a directory containing both a symlink and a directory with the same name, the symlink will be followed and filled with the contents you put in that directory due to a refactoring mistake

and, as the nix daemon usually runs as root (with the nix store mounted read-write), it's possible to write files into e.g. /run/current-system/etc/systemd/system. and as such, and get persistent root access from unpacking a malicious NAR.

now do you make Nix read a NAR? well... there's two primary ways

any untrusted user that can talk to the nix daemon can write NARs that are either content-addressed, or signed by a trusted key, into the Nix store;
...and any binary cache can do this as well, as the daemon will fetch nar files from the binary cache.

now this vuln would be evil but local privesc only if this was all, except for a very funny second issue:
the signature on NAR files is validated only *after* unpacking the NAR

so any malicious binary cache can reuse the signature of, say, a store path on cache.nixos, and (this is very likely, of course) if the nix daemon trusts the signature, it will end up unpacking any nar of the cache's choice without checking that the signature (or even hash!) matches

in certain cases (e.g. there's a symlink pointing to root in a trusted nar) this can even be done entirely silently, which is .. very bad.```

Sources

Update 2024-09-11: Update version of nix released.

3 Likes