@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 Oh hey Mojang is like this too. Then when you make a public version they mark it as private and prevent you from updating it (in my experience).
@gudenau @puckipedia @ktemkin
We don't have a policy like that, because why would we? Puck was invited late, on possibly the permission level was misconfigured from what I'm reading.
I wish we had time for such bs. We're not corporate, despite what the open letter might have made you believe. (Again, I wish, because then we might actually have more time to solve the issues of the past 20 years)