Live data from Hacker News

Nix 2.24 is vulnerable to (remote) privilege escalation

puckipedia.com

31–40 of 81 posts

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

#31

Earlier quoted context omitted.

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

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

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

#32

Earlier quoted context omitted.

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

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

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.

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

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

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

#34
post #23

Earlier quoted context omitted.

Why call it "Cppnix"?

Because it's written in C++ and the fork plans to rewrite in Rust?

Also there's too many things called Nix.

There's the overall project, the language, and the primary interpretation. It's also why you'll sometimes see nixlang to refer to the language.

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

#35

Earlier quoted context omitted.

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

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.

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

#36
post #10

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.

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

#37

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.

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

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

#38
post #34
post #23

Earlier quoted context omitted.

Because it's written in C++ and the fork plans to rewrite in Rust?

Also there's too many things called Nix. There's the overall project, the language, and the primary interpretation. It's also why you'll sometimes see nixlang to refer to the language.

Thought was the norm using capitalized for language and lower case for the tooling. So Nix/nix, like AWK/awk and Go/go.

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

#39

Earlier quoted context omitted.

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

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…

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
Post reply on HN