@puckipedia@puckipedia.comokay so. nix 2.24+ vuln: nar unpacking is fucked, and local unprivileged users, or any binary cache you have configured, can just Get Root on your system
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.
at this point the disclosure timeline has passed; and a point release was even made after the vulnerability was well known by the entire team (GHSA-h4vv-h3jq-v493 was opened a day before the point release); and the severity of the vulnerability is high enough that i want people to be aware of this issue
(it's possible to mitigate this issue by downgrading to Nix 2.23, or setting allowed-users to only trusted users; and making sure any binary caches you have set are https and very trusted.)
@puckipedia What the heck?? We were about to release the fix after getting your feedback. Did you not receive a message from Tom?
@roberth @puckipedia Can we set up some kind of real-time comms between the lix and cppnix core teams?
If schedules could be communicated (or if you could keep our devs on the loop) I think we could help to prevent missing each other.
It's very hard to get any comms to y'all and get a solid response, and that seems like something we should fix.
@ktemkin @puckipedia Puck and Tom were in touch, we're all on Matrix, we have a responsible disclosure document thingy on the GitHub repo. How could that not be enough?
I'm all for a hotline, sure, but why would Puck do this when she's already in touch?
Anyway, the damage has been done and I can't trust Puck again. This is really really bad.
@puckipedia@puckipedia.comRegarding "Responsible disclosure document thingy"; I'd like to remind you that last time I used this, it took a good while for the NixOS security team to get in contact with y'all, and the end result included GHSA-wf4c-57rh-9pjg, which has been open since february 12th (with the description of the vuln being, literally, "blabla") with zero response from anyone on the Nix team since March 8th, even after responding in the advisory multiple times, and specifically noting this in _this_ report too.
After disclosing this vulnerability, Tom told me (September 2nd) that he created the advisory, linked it, but did not give me privileges to see it. I responded to that in 15 minutes, and got _no response_ from him until earlier today (as he was on vacation). I'd not call this "being in touch". At no point during that did any other member of the Nix team proactively contact me with any information, and as a point release had been made after this vulnerability was well known by the whole team, I did not feel confident that a release would happen in reasonable time. I had already said that I considered publicly disclosing this in a week after reporting it, and at no point was I told to hold off, or when a release was happening. If I was told this, I would've waited no problem.
At this point, my trust in the Nix team actually dealing with security issues responsibly is gone, and has been for _months_.
@puckipedia @roberth @ktemkin Also, a reminder that the only reason the FOD sandboxing bug was dealt with with halfway ok communication (special matrix room with relevant CppNix team members, etc) was because I coördinated the response from outside and pushed that to occur. And yet that one also did not get fixed in a timely manner even once reported the second time (two years later).
There is a serious gap in security process in CppNix.
@leftpaddotpy @puckipedia @ktemkin I haven't been on the team for two years, and I haven't been assigned to a security issue. I now wish I had been assigned.
@leftpaddotpy @puckipedia @ktemkin I don't see any two year old advisories in the GitHub system. I guess the process might have been different then? (I would guess just handled by Eelco, possibly involving the Nix_OS_ security team?)
Actually I think I'm almost exactly 2 years on the team, but barely getting to know the code back then.
@puckipedia@puckipedia.com@roberth @leftpaddotpy @ktemkin I'd have to double check, I don't have great memory of back then; but I am pretty certain it was reported to a NixOS security team member at the time. (Note that the Nix security disclosure policy today does actually involve talking to the NixOS security team, and not to the Nix team.)
@puckipedia @leftpaddotpy @ktemkin I don't know why that is, but it's clearly not working. I'll suggest that we change it to contact the Nix team directly.
@roberth @puckipedia @ktemkin if you want to steal parts of or take inspiration from the policy i spent about 45 minutes writing 5 months ago after the fod bug, here you go: https://pad.lix.systems/lix-security-policy#