functional.cafe is one of the many independent Mastodon servers you can use to participate in the fediverse.
functional.cafe is an instance for people interested in functional programming and languages.

Server stats:

221
active users

Public

okay 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 I'd like to apologize for my harsh initial reaction. After our conversations here on Mastodon and with the team, I have learned that our disclosure process is broken.

Puck did the right thing from her perspective, and that should have been sufficient for us to handle her report properly.

We now focus on protecting our users from harm, and we need to reconsider how we go about things because the current situation is not acceptable.

Quiet public

@roberth @puckipedia
It’s sad to see the sorry things that have happened in this community since summer and even before. Now that you’ve apologized, please make it better. Don’t ignore people wanting to help fix the codebase and don’t call them irresponsible after they’ve tried to do things how they were supposed to.
This is how forks are made and projects die.