Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nix 2.24 is vulnerable to (remote) privilege escalation

puckipedia.com

Post reply on HN
Print view View original

11–20 of 81 posts

Re: Nix 2.24 is vulnerable to (remote) privilege escalation

#11

Post by exe34 »

johnklos wrote: post #9
jaculabilis wrote: post #4

Earlier quoted context omitted.

> 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.

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, bu…

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

Re: Nix 2.24 is vulnerable to (remote) privilege escalation

#12

Post by anonfordays »

one-punch wrote: post #6

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://…

[flagged]

Re: Nix 2.24 is vulnerable to (remote) privilege escalation

#13

Post by clhodapp »

takeda wrote: post #7
one-punch wrote: post #6

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://…

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

Re: Nix 2.24 is vulnerable to (remote) privilege escalation

#14

Post by elorm »

johnklos wrote: post #9
jaculabilis wrote: post #4

Earlier quoted context omitted.

> 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.

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, bu…

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...

Re: Nix 2.24 is vulnerable to (remote) privilege escalation

#15

Post by myst1c »

clhodapp wrote: post #13
takeda wrote: post #7

Earlier quoted context omitted.

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...

Re: Nix 2.24 is vulnerable to (remote) privilege escalation

#16

Post by one-punch »

anonfordays wrote: post #12
one-punch wrote: post #6

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://…

[flagged]

I have not been following closely this back story, so I am not aware of such ban, or that (allegedly) Lix is Pierre Bourdon’s software.

I am not affiliated with Nix (Cppnix) or Lix.

Re: Nix 2.24 is vulnerable to (remote) privilege escalation

#17

Post by johnklos »

elorm wrote: post #14
johnklos wrote: post #9

Earlier quoted context omitted.

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, bu…

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 di…

> 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?

Re: Nix 2.24 is vulnerable to (remote) privilege escalation

#18

Post by elorm »

johnklos wrote: post #17
elorm wrote: post #14

Earlier quoted context omitted.

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 di…

> 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 go…

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

Re: Nix 2.24 is vulnerable to (remote) privilege escalation

#19

Post by soraminazuki »

johnklos wrote: post #2

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 plent…

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.

Re: Nix 2.24 is vulnerable to (remote) privilege escalation

#20

Post by max-privatevoid »

one-punch wrote: post #16
anonfordays wrote: post #12

Earlier quoted context omitted.

[flagged]

I have not been following closely this back story, so I am not aware of such ban, or that (allegedly) Lix is Pierre Bourdon’s software. I am not affiliated with Nix (Cppnix) or Lix.

Why call it "Cppnix"?
Post reply on HN