@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 @puckipedia Members of our team have been trying to get comms going with you for -months- over a past disclosure that has died on the vine, and which is still unmitigated on your side.
If we can't get you to e.g. cherry-pick a trivial remediation in a matter of months, we have a responsibility to make sure that issues are at least brought to the public's eye.
First & foremost, we're responsible for upholding the trust of our users. If you've the same goal, please start communicating.
Meanwhile, if you want to blame anyone, blame me.
Infosec best practices generally suggest publicly disclosing vulnerabilities immediately when dealing with a 'vendor'/project who has been non-responsive.
I advised Puck to give you a very short span rather than post the vuln outright out of respect for you and your team. I believe that was communicated, and wasn't aware of your team ever communicating that you wanted more time than that.
@ktemkin @puckipedia
Ok, well, we're just a team of volunteers and I thought the issue was being handled while I was away last week.
@sandro@c3d2.social@ktemkin @roberth You probably shouldn't do that if you are sitting with half a leg in the same boat.
I think you probably would also want that security issues from the nix side are communicated and staying in a good relation is probably never bad. Those kinds of actions are just not supporting that.
I think everyone involved is actually doing well at making progress and growing as people and a community?
Sometimes things need to come to a head so we can recognize what's wrong with our processes and make improvements -on both sides-.
I don't think this went as well as it should have, but I also think that -- counter to the point you're trying to make -- real progess is actually being made.
@ktemkin @puckipedia What is your definition of trying? Doing the exact same thing over and over without result or something?
The Nix community is on many platforms through which it can be reached and one of them is enough to establish contact with any of the team members.
As far as I know, team members have reached out in multiple ways - including in person at events - and been summarily ignored.
There's obviously a communication issue here, and I'm literally reaching out to you to try to get *something* that works, because we all want Nix-based technologies -- and their users -- to thrive.
If this is due to a lack of resources on your end, please let me know how we can help. As far as I'm concerned, we're all in this ecosystem together.
@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#
@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)
@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.