Security Advisory: Privilege Escalations in Nix, Lix and Guix

[emily]

@srd424

Honestly, the impression I get is that unless you’re running a public nix CI system, there’s no great panic. As a “normal” NixOS user, anything you build is presumably ending up in your system configuration anyway, potentially getting executed as root, or the very least your normal user. If any of that’s coming from untrusted sources, you presumably have bigger problems than a sandbox escape.

FWIW, this was what I was saying in the original thread but I somewhat regret the take:

• I didn’t have a root escalation on my bingo card; I expected a mundane escape to a sandbox build user, which is not as exciting.

• I forgot that we don’t set allowed-users by default, so it’s not just derivations you cause a build of yourself that are at risk, it’s anything that can access the Nix daemon, potentially including random service accounts if they don’t have particularly hardened systemd service setups.

I stand by “it’s pointless to try and avoid building your configuration”, but I do actually think this is a really serious vulnerability, one of the worst it’s possible for Nix to have; you should prioritize getting a fix deployed on your systems. (I guess even worse would be arbitrary code execution as root in response to a binary cache response prior to TLS certificate validation…)

We should probably harden the default allowed-users in NixOS, but it’s hard to do backwards‐compatibly – it might break automated build setups.

@roberth

The commits are recent due to rebasing. Only the check that build-dir isn’t world-writable was added in the past weeks. Most of the work was done early on.

Thanks, that makes sense. But I’m still confused about the timeline here for a vulnerability of this severity; what was happening for the months in between? The build-dir check wouldn’t have been necessary to mitigate this on common systems using the default configuration, right? If the Lix patches the Nix fix was based on were written 2–3 months ago and most of the Nix‐side porting work was already done around then, wouldn’t it have been possible to coordinate to get an advisory and fixes out sooner, rather than running right up to the 90 day deadline?

I realize that the Nix team have other commitments and that it’s not always simple to rush out a security patch immediately. But any user being able to escalate to root on a stock NixOS system is a big deal, and if there were adequate patches to fix that within days to months after report I’m struggling to understand what went wrong here for the process to take 90 days.

This isn’t the first time recently that handling of a Nix vulnerability has reportedly stalled out for months and the NixOS security team reported in Change security policy to report directly to the Nix team · Issue #11468 · NixOS/nix · GitHub that they have spent months asking for triage updates on Nix security issues. I know there were changes made after that, so I’m hoping we can get a better understanding of what happened this time.

I’m worried that there are process failures here that are systematically undermining the security of NixOS and users of Nix on other Linux distributions and macOS. The Nix daemon is a pretty substantial attack surface that is present on almost all NixOS systems. I know that nobody on the Nix team is doing it as their full‐time job and that it’s hard to say whether things could have gone differently in the absence of a counterfactual. But in this case we appear to have one: it seems like the Lix team was ready to deploy final fixes over a month and a half ago and had a basic fix within days. I’m hoping we can get more light shed on this by the Nix and NixOS security teams so that we’re better prepared for the next time there’s a serious vulnerability in Nix.