Security Advisory: Privilege Escalations in Nix, Lix and Guix

Announcements Security
43

6 posts were merged into an existing topic: Critical correctness bug in Lix

44

Would this be enough to verify that one is up-to-date with the latest fixes? I’m on nix darwin 24.11.

> nix --version
# nix (Nix) 2.24.14

> EDITOR=cat nix edit nixpkgs\#nix | \
    grep -C3 patches/ghsa-g948-229j-48j3-2.24.patch
#      nix_2_24 = commonAutoconf {
#        version = "2.24.14";
#        hash = "sha256-SthMCsj6POjawLnJq9+lj/UzObX9skaeN1UGmMZiwTY=";
#        patches = [ ./patches/ghsa-g948-229j-48j3-2.24.patch ];
#        self_attribute_name = "nix_2_24";
#      };
45

Version updates were merged like a day afterwards, too.

2 Likes
47

That’s not very concrete. File an issue if anything is broken or temporarily remove the reason it prevents you from upgrading.

48

Rory McNamara from the Snyk Security Labs team, the initial reporter of these issues, has published a blog post for those of you who enjoy technical reading: NixOS: Declarative Management, Imperative Privilege Escalation - Deep Dive with Snyk Labs | Snyk Labs

7 Likes
49

No, you have to also assert that your nixpkgs is pinned and that the deployed nix matches up with that input.

A quick and easy way to confirm that is to check if the result symlink nix build nixpkgs#nix produces matches up with the top-level directory of the package the nix binary in $PATH is in (or some cool nix eval command I can’t think of).

You have to both ensure this and that the patch is added (as you did) to confirm the running nix has the patch.