Live data from Hacker News

Nix 2.24 is vulnerable to (remote) privilege escalation

puckipedia.com

1–10 of 81 posts

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

#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 plenty of time to do something about it.

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

#4
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…

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

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

#5

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.

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

#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://lobste.rs/s/ixb3v7/nix_2_24_is_vulnerable_remote_pri...

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

#7

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)

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

#8
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…

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

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

#9
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…

> 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, but the "we're too important to respond" shtick is old and tired.

Post reply on HN