@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.
@roberth @ktemkin @puckipedia The vulnerability was disclosed at the end of the stated timeline of one week. I don't see any other obligations on the reporter tbh: she disclosed it at the time she said in advance she was going to do it.
I also made sure to block the nixpkgs PR to make sure nobody *tried* to make 2.24 the default to reduce the impact.
You missed your deadline. It's that simple. Also the security advisory iirc had misconfigured permissions such that puck couldn't read it.
@leftpaddotpy @ktemkin @puckipedia Ok, the deadline was not shared with me. I think a week is short for a volunteer team, and if I had known about this short deadline, I would have been on top of it despite my work trip.
@leftpaddotpy @ktemkin @puckipedia
Actually Tom can not confirm that a 7 day deadline was communicated. I've read his matrix chat with Puck and it does not contain a deadline
@puckipedia @leftpaddotpy @ktemkin Fair enough. You did say it, and you did get a response. It would have been wise to remind him for something as important as that, but ok, fair enough.
@puckipedia@puckipedia.com@roberth @leftpaddotpy @ktemkin (i realise in retrospect this is misinterpretable; i assumed at the time that the context would be clear enough to at least double check the plans.)
@roberth @ktemkin @puckipedia that's a very silly communication mistake if so and I'm sorry it occurred, if there was indeed no deadline communicated. I was told that it *was* communicated and was operating under such an assumption.