Nix 2.24 is vulnerable to (remote) privilege escalation | Hacker News Reader

Nix 2.24 is vulnerable to (remote) privilege escalation

puckipedia.com

66 pointstodsacerdoti78 comments

I don't get why someone who responded to this calls this something other than responsible disclosure. puck clearly writes, "at this point the disclosure timeline has passed".

It's on Nix to meet the disclosure timeline. Missing that is Nix being irresponsible, not puck.

I see this often, and it's not a good look when people would rather punish the reporter of an issue rather than the organization that was given plenty of time to do something about it.

> the organization that was given plenty of time

One week doesn't seem like "plenty of time" to me. The guy who ack'd the initial report and created the vulnerability tracker in GitHub was on vacation.

Reporter’s defense: https://lobste.rs/s/ixb3v7/nix_2_24_is_vulnerable_remote_pri...

Someone who writes a response to a security vulnerability report, includes nobody else in the discussion, then leaves for vacation within 15 minutes of sending that report is irresponsible. Giving someone a week to respond is not unreasonable. If nobody responds in a week, it can safely be assumed that they don't take security seriously, and the responsible thing is to let the community know.

Spin it how you like, but the "we're too important to respond" shtick is old and tired.

that's a bit entitled. I'm coming over for dinner, I hope you're prepared.

This isn't "I'm entitled to free dinner", this is "your dinner guests are getting sick from food poisoning, and you're demanding I don't tell them".

it's free food.

So it's okay to knowingly poison people and cover up the fact, as long as you don't charge them?

I don't think anybody got poisoned.

This is a very poor take.

The security team is composed of unpaid volunteers who work on numerous time-sensitive projects simultaneously. You may not be aware, but since a group of maintainers and contributors left earlier this year to form their own fork called "Lix," there have been many vacant positions across several Nix teams.

They actually held a meeting about the security issue earlier in the day before the disclosure and had reached out to the reporter(0).

The sense of entitlement here is pretty much rank because any animosity between the Lix team and Nix teams going forward will only be to the detriment of the Lix team. Everyone's really tight at the moment and no one is paid for this much drama every couple of months.

https://discourse.nixos.org/t/2024-09-09-nix-team-meeting-mi...

> before the disclosure and had reached out to the reporter(0).

First, the only link you provided doesn't look to be related to this issue.

Edit: I see it bizarrely redirects to "https://discourse.nixos.org/t/iohk-hiring-devops-with-nix-ex...". What happened to the minutes?

Second, I understand that it's run by volunteers, that they might not have the humanpower they need, and so on - as a volunteer who spends a good bit of time working on an open source project, I get it - but if someone's about to go on vacation, they shouldn't just fire off an email with no information and leave. They should reply with information: "I'm leaving for vacation and we have no other people to handle this", or "I can't do anything myself for the next week, but let's cc someone else", or something.

Also, when they finally did reach out, they didn't say it was being worked on, nor did they ask for an extension, nor give any kind of timeframe. Creating a point release means volunteers were working on things, and releasing it without the fix means they didn't take the security report seriously.

Unless someone shows me something that doesn't point to a completely opaque process, I have to say I would likely've done the same thing.

After all, if I reported something to an organization, and the organization didn't assure me they were working on it and offer some kind of time frame, and in the meanwhile released an update that didn't have a fix, I'd take that at face value: they just don't care about security (or don't understand the security implications, which is even worse - there's nothing wrong with being ignorant about a thing, but deciding to do nothing about a thing because of ignorance is inexcusable).

So was puck being malicious by releasing this information? I don't think so. If I were a Nix user, I'd want to know about a security issue that might affect me, so I'd welcome this as someone trying to help Nix users. If it hurts the Nix organization, then tough cookies. They should've taken action and communicated better.

Is the issue even fixed yet?

Can't tell what happened to the earlier link but I've fixed the it.

Puck was being malicious in releasing the information. There's no favourable way of describing disclosing a vulnerability on social media because the maintainers didn't meet your 7 day deadline.

It's more of "we're forcing their hands since they haven't met our expectations yet" thing.

There's so many ways they could've gotten a timely fix without "doing everyone a favour by not fully disclosing the entire 0 day." approach but like you said .... tough cookies all round.

And to answer your final question, there's a patch available.

https://github.com/NixOS/nixpkgs/pull/340885

That's not a patch. It's just downgrades the nix version to 23 in nixpkgs.

It doesn't help people who are already using the vulnerable version and also new users cuz installers install latest versions

> Puck was being malicious in releasing the information.

[citation needed]

> There's no favourable way of describing disclosing a vulnerability on social media because the maintainers didn't meet your 7 day deadline.

personally I'm grateful he didn't sit on a remote privexc vulnerability for 90days when he was confident it wasn't going to be fixed. I think you're conflating public disclosure (security though obscurity) with real harm, compromise due to the bug. If Puck found it, others who would gladly sell it for coin on the black market, would have found it.

Calling the reporter malicious is not constructive and does not help Nix (even if you are right). From all I can tell, there was no request to extend the deadline or proactively coordinating disclosure when the reporter pushed for it. That would have been preferred and could have avoided this situation. I would hope for a later postmortem incorporating the lesson of more proactive communication with reporters.

That the Nix team didn’t cooperate is a trivially disprovable excuse being pushed by people surrounding the fork.

https://matrix.to/#/!VRULIdgoKmKPzJZzjj:nixos.org/$tJgEBGqKs...

Can we please stop this polarizing drama, from both sides? I never said that anyone wasn't cooperating. Quoting your link:

> > is there any update on the root escalation vulnerability in 2.24?

> Eelco is working on it, there's a patch on the GitHub advisory, we plan to get it out on Monday, but no promises yet if everything will get done by then

This is what I mean is not sufficient in terms of disclosure coordination... Doesn't seem like anyone was necessarily acting in bad faith, just mutual frustration and room for improvement on professionalism on all sides. Though I'd hold NixOS maintainers to a higher expectation of professionalism than random independent security researchers. The important thing is that people draw the right lessons. "The X people suck" isn't a valuable lesson for any value of X. And if you're seeing bad intent on the reporter and them trying to prove a point; well yeah, maybe, and point proven? Processes should cover for these eventualities.

The thing is, the reporter is not a random independent security researcher. She's a core team member of Lix, the fork, and is no stranger to the Nix community. This incident directly relates to the wider conflict between the two projects. That's why people are upset.

So you're saying out loud that the person reporting the issue matters. It shouldn't matter who tells you that you have a security issue.

Nobody ever said it isn't okay to report security issues. This is about dumping 0 days on social media when you know fully well that the other side is cooperating and working on a fix. The who in this case matters because the reporter knew how the Nix community works, knew it was hostile thing to do, and did it anyways.

Again,

https://matrix.to/#/!VRULIdgoKmKPzJZzjj:nixos.org/$tJgEBGqKs...

What I meant is crystal clear if you read what I was replying to. Please don't take it out of context to spin a story. You did it in your original comment, and you did it again right here.

No, I'm really not trying to take things out of context, but what you wrote really makes it seem like the person who reports it matters.

Ignoring that, I agree that it's a dick move, but it's like our famous "well, technically" memes - the delivery might matter, but in the case of security issues, it really doesn't matter as much as the actual content.

"You have an issue, and I'm going to be a dick and release it in a week."

Yes, that would be a dick move, but someone acting like a dick doesn't mean that the Nix team shouldn't address the issue within that week, even if it does feel like extortion.

Also, those matrix links say nothing. I'm not sure what we're supposed to do with them, but I'm not downloading software to see whatever it is you want to share.

> The security team is composed of unpaid volunteers who work on numerous time-sensitive projects simultaneously. You may not be aware, but since a group of maintainers and contributors left earlier this year to form their own fork called "Lix," there have been many vacant positions across several Nix teams.

This is not true, there have been many vacant positions across several Nix teams because the original project has been unable to keep these people. When challenged about this inevitable situation of depleted labor, the answer of people involved in leadership was, "It's OK, we will have new people joining us anyway.".

Lix has been trying to connect with the Nix maintenance team, with very timid results from the Nix side. We continue to hope this will lead to a better cooperation.

Also, you say that they are "unpaid volunteers", the Nix maintenance team is composed of folks who have full-time responsibilities in VC companies who sells Nix-based products.

> This is not true, there have been many vacant positions across several Nix teams because the original project has been unable to keep these people.

Might it have something to do with the culture of bullying and intimidation that you were responsible for on the Discourse?

[1] https://discourse.nixos.org/t/lix-an-independent-variant-of-...

And this?

https://discourse.nixos.org/t/delroths-muting-in-the-moderat...

I've clicked through a bunch of your references and am yet to see any of the "bullying" you keep talking about across the thread... Please be more concrete and on-point or this is just ad-hominems, insinuations and drama...

I've clicked through a bunch of the references and definitely see lots of crybullying and clearly breaking the CoC. There was an example where the subject of this thread was temporarily banned.

The crybullying in the nearby comment is part of the observation. The two people in that thread have been ganging up on others in the Nix community for months now. Another thread[1]; note the same couple people.

> For example, you were able to dedicate two hours twice a week to attending meetings that you were not welcome at. A lot of people were not able to do that; they did not have the time or energy levels to be able to afford that in the first place.

> What I’m trying to say here is: yes, your situation sucked, and it should not have been necessary. But imagine how much more this might have sucked for other people who did not even have the affordances that you had to cope with this(...)

Then the other person:

> Your projects had multiple issues that were clear and apparent to outsiders that leaked outside your team and had to become a Nixpkgs problem (as I had to become against my own will a Nix maintainer in Nixpkgs). You never acted on that, you never took the necessary actions to show that you (:= your team) know how to manage an open source project.

(...)

> I feel you on the sadness. I am sorry you feel like this. Likewise, I remember what it was for me for the past year to feel like shit when I received this message

This is pretty classic abusive breaking someone down to build them up and tell them how the abuser was much worse off, and the reports from several meetings are much worse. Hitlists of people to remove from the project, that sort of thing. The power games going on are frankly sick, and the most unprofessional thing I have ever heard of in an open source project.

All I'm saying: try to get the other side's perspective. I think there are many people tired of this behavior. When it is presented with a one-sided perspective, the solution seems obvious, but this hostility has colored the past few months of interaction in the Nix community.

[1] https://discourse.nixos.org/t/objection-to-minority-represen...

Normally I'm sympathetic to claims about people being entitled to work from open source projects, but in this instance, I don't think this is the case. If this were a request for a feature or a bug without significant security impact, expecting any sort of timeline at all would be unreasonable, but I don't see how not having enough people to work on a project would imply that users should be left vulnerable for longer. In my opinion, it's much more "entitled" to demand that a known security bug in your own code base be hidden from your users because you would prefer to keep working on whatever you're currently doing.

> The security team is composed of unpaid volunteers who work on numerous time-sensitive projects simultaneously.

If the nix volunteers aren't held to reasonable security defect reporting standards, why do you hold the vulnerability reporter to higher standards? I'd say, if the rule is volunteers are able to YOLO with other users' security so can the reporters right?

> If nobody responds in a week, it can safely be assumed that they don't take security seriously, and the responsible thing is to let the community know.

That's an if that did not happen:

> Eelco is working on it, there's a patch on the GitHub advisory, we plan to get it out on Monday, but no promises yet if everything will get done by then

https://matrix.to/#/!VRULIdgoKmKPzJZzjj:nixos.org/$tJgEBGqKs...

More context:

> The vulnerability report doesn’t mention it directly, but the discussion thread about it on Fedi gives some more context on that deadline: the reporter has had several previous vulnerability reports completely ignored by the Nix development team, including one open since February and still untriaged. The Nix development team received and acknowledged this new Nix 2.24 vulnerability on August 30th (so, > 9 days ago) and they seem to have mostly sat on it until today (the reporter received no further comms), to the extent that a new point release of Nix was released a few days after the vuln was reported and did not contain a fix.

Source: https://lobste.rs/s/ixb3v7/nix_2_24_is_vulnerable_remote_pri...

The first one from Feb: https://matrix-client.matrix.org/_matrix/media/v3/download/p...

It's a community project run by volunteers but I don't think such response ("Impact: blabla") to a vulnerability gives a good impression to your users.

This is a "both things are true" situation.

There is a group working to smear Nix, Eelco, and everyone related to the project who are now playing the innocent victims and pretending they didn't sign a letter that started with the words "Eelco Dolstra’s leadership is corrosive to the Nix project." This is where people citing GH issue templates that contain "blabla" reinforces the narrative that the people who were working with Puck to solve the issue before she dropped a zero-day in public are somehow irresponsible. It is just that - a narrative. Everyone cannot stop staring at the sheer amount of narcissism on display in support of this narrative.

The grain of truth is that it's probably not Puck's fault, and the security disclosure process could also be improved since it's evident a ball was accidentally dropped somewhere. More points of constant contact involved in solving these problems are good for everyone.

If you know that much about the ongoing disagreements, you know very well that the volunteers weren’t given “plenty of time.” The author deliberately chose a short deadline and admits that. That deadline wasn’t known to Nix core team members because it wasn’t mentioned where the main discussion took place. This is all public information available in the linked Mastodon thread.

If you’re going to choose a short deadline, you should at least make sure that the other side acknowledges it. Or at least warn before posting 0 days on Mastodon. That’s what “responsible” people do. The reason this didn’t happen is because of the ongoing drama between Lix and Nix. Very unfortunate.

The deadline was literally publicly available in the public matrix channel which anyone can read even without a matrix account. The reporter also said they were willing to extend the deadline, if the nix team reached out. They didn’t and chose to ignore the publicly available messages. Given past experiences (it’s not the first vulnerability that was outright ignored) I think it’s fair to say “you have a week to respond, otherwise I’m dropping the vuln”. If only they responded and said “hey, we’re working on this but we need more time” nothing would’ve happened. But they didn’t.

That's just flat out false. Both parties admit that the author and Nix maintainers were in touch regarding this vulnerability. Public accounts and meeting minutes prove that Nix maintainers were preparing a fix.

The short deadline was only mentioned once, again separate from where the main discussion took place. There are dozens of Nix Matrix channels and so many messages being exchanged there every day. It's easy to miss. The author isn't a newcomer to Nix and most certainly knows this too. So the way the author dropped the 0 day on social media was outright and needlessly hostile considering that the vulnerability was acknowledged and being worked on.

We must have different definitions of “being in touch”. Sending an email and going on vacation, then actively ignoring incoming messages isn’t being in touch. And I don’t blame the person from the Nix team who went on vacation, but not forwarding the researcher to anyone else is solely on the nix team. They responded to the message in the matrix channel which included the deadline so they were well aware of it. If they knew they wouldn’t be able to release the fix before the deadline, they could’ve (and should’ve) asked for an extension. Which they did not

This message was sent last Sunday in a public Matrix discussion involving the author.

> Eelco is working on it, there's a patch on the GitHub advisory, we plan to get it out on Monday, but no promises yet if everything will get done by then

https://matrix.to/#/!VRULIdgoKmKPzJZzjj:nixos.org/$tJgEBGqKs...

In what world is this "not being in touch," "actively ignoring messages," or "not forwarding the researcher to anyone else"? Also, Nix maintainers clearly state in the Mastodon thread that they weren't "aware" of the deadline. Very different definitions of words indeed.

I reported to Alpine that the security tracker has an incorrect approach of correlating packages and CVEs. At the time the security tracker had incorrect data for over 6 months without anyone caring about it.

I forked it on their gitlab, patched it, and merge requested it.

Nothing happened 3 years later, still the same. And they still doxx me from time to time. Mostly on github and shitter, so I don't see it early enough anyways to react to it.

Assholes are always gonna be assholes online. The only way to deal with this is to walk away and not care about those toxic communities. There's better places on the internet and your time is just wasted effort in those chan-like areas.

> And they still doxx me from time to time. Mostly on github and shitter, so I don't see it early enough anyways to react to it.

I'm somewhat glad I'm not the only one with problems like this in the Alpine community.

From my perspective it's just sad observing how a project with such huge potential derailed so quickly because of the wrong (read as: very insecure in their ego) people managing it.

It's just childish behavior at this point.

Possibly of note, pkgs.nix on nixpkgs (stable and unstable) is from the 2.18 series, and so not vulnerable to this.

Can choose to install `latest` (or `2_24` explicitly or even `git` that builds nix directly from master) version which before the submitted disclosure was set to 2.24. Has since been changed `latest` to install 2.23 instead and `2_24` and `git` have been marked as vulnerable.

This is fixed in 2.24.6: https://github.com/NixOS/nix/releases/tag/2.24.6

Can someone link to the actual fix? It's a bit hard to navigate the git history for me...

I think it is https://github.com/NixOS/nix/commit/12fa019ae558641df0a23a79...

How can such a simple code change fixes such a big vulnerability?

Or maybe it's https://github.com/NixOS/nix/commit/35575873813f60fff26f27a6...

the commit log is tad unclear and the GHSA writer didn't bother themselves with linking the offending code

Thanks, that one seems likely.

Hmm, though this seems to affect the case-hack thingy only, which seems like a macos-specific feature...

technicals aside, as they are now resolved or being resolved in one manner or another, i would really like an understanding of precisely where the breakdown in communication occurred. i have thus far heard conflicting reports that indicate either the relevant nix org team dropped the ball, or was doing things right and got the rug pulled out from under them, which indicate respectively that puck was either exercising the best option available, or, well, not. can someone establish a proper timeline of events?

https://lobste.rs/s/ixb3v7/nix_2_24_is_vulnerable_remote_pri...

It seems like a binary cache can already get root on your system - it is serving you binaries to run, often as root. Don't authorize a binary cache you don't trust.

The problem is that arbitrary users can cause nix to unpack arbitrary nars and edit arbitrary files that user shouldn't have permissions for. The system doesn't have to be configured to trust any particular binary cache. This is just straight up persistent privilege escalation, plain and simple.

> It seems like a binary cache can already get root on your system

No, rootless Nix is pretty well supported.

Wondering how vulnerability applies outside NixOS. Does Nix outside NixOS also has such access over the system?

lix [1] might be less affected. Pierre Bourdon noticed that lix refactored surrounding code 4 months ago [2], and a comment claims that this Lix commit at least patched a different vulnerability GHSA-wf4c-57rh-9pjg [3].

To use lix instead of nix, set `nix.package = pkgs.lix` in your NixOS/home-manager configurations.

[1]: https://lix.systems/

[2]: https://mastodon.delroth.net/@delroth/113110218127456491

[3]: https://lobste.rs/s/ixb3v7/nix_2_24_is_vulnerable_remote_pri...

What's the difference between Nix and Lix? The website is still not entirely clear.

I mean as an user, why would I want to use it (besides avoiding this vulnerability)

Lix is a (nixpkgs-compatible) fork of Nix, led by Nix community members that don't get along with the core Nix team.

At this point, the primary reason to switch to Lix would be if you trusted the Lix folks more than the core Nix team

There are plenty of fantastic reasons not to, despite the prior issues with Eelco's leadership style. The NixOS Starknet situation[1] was very suspicious and involved many of the wrong incentives for an open source project. One of the primary people involved was trying to get the drops transferred to other people's accounts (getting around geofencing prohibiting US withdrawals too). So it is virtually guaranteed that is being transferred toward something other than the NixOS binary cache despite it being emphasised it would go there. I guess it will be going to "save Nix together" for the fork. All €20 000 or what-not of it.

At least Lix is doing some interesting things with the language and fixing some long-standing regressions, but some of the people involved seem to enjoy standing next to others doing the work whilst they loudly take credit, and participating in cryptocurrency ponzi schemes using open source as the vessel.

[1] https://discourse.nixos.org/t/starknet-cryptocurrency-contri...

Lix claims to have a more welcoming community, but I too often see prominent members gloating about every Nix bugs and implementation details on Mastodon and elsewhere so YMMV.

More welcoming how, by stabbing the heart of Eelco with shitty demands? Very welcoming.

If you look elsewhere in this thread, many of the bullies are doing PR for Lix and trying to use this situation to their advantage. What no one is disclosing to people is that their fork of nixpkgs (ForkOS) is nearly done, so pointing people to it is going to be almost entirely in their benefit. But, why would sociopaths tell people that when they can just publicly embarrass people instead?

The amount of gaslighting here is frankly astounding. There were some good developers who went over to Lix but also a few pathological liars and primary school bullies. People don't know half of the abuse going on.

Didn't get along is an understatement. They gaslit and destroyed the little bit of leadership structure of NixOS had through harassment and bullying.

Watch out, they may call you the problem when they're accidentally talking about themselves...

It's very bad and one can simply look through the Discourse and GitHub issues from earlier this year to discover the full extent of the problem. Watch how they turn a security issue into PR now, this is just a microcosm of the dishonesty.

I think you are referring to 4 out of 5 NixOS board members quitting

https://old.reddit.com/r/NixOS/comments/1dqn9os/4_out_of_5_n...

Reply on news.ycombinator.com