Live data from Hacker News

NixOS and reproducible builds could have detected the xz backdoor

luj.fr

111–120 of 192 posts

Re: NixOS and reproducible builds could have detected the xz backdoor

#111

Article says that distributions should get source code directly from the VCS (for instance Github) rather than the traditional installation tarball. I don’t see what this solves though. Couldn’t a malicious maintainer simply add binary blobs directly to the source code repository? The author suggests Github is trusted, as though Github validates code in some way. Which of course it does not.

What this solves is the problem that often "what is reviewed" is different from "the source code used to build the software". Verified reproducible builds could have countered the xz utils break, SolarWinds Orion subversion, and many others. It's worth doing.

But would that have solved anything here? The main maintainer was overwhelmed. The back door was obfuscated inside a binary blob there for so-called testing purposes. I doubt anyone was reviewing the binary blobs or the autoconf code used to load it in, and for that matter it’s not clear anything was getting reviewed. Fetching and building straight from GitHub doesn’t solve that if the malicious actor simply puts the binary blob into the repo.

Re: NixOS and reproducible builds could have detected the xz backdoor

#112
post #101
post #35

Earlier quoted context omitted.

> This would make it convenient to run every single process with restricted privileges, including no access to ~/ Please no. I understand why Flatpaks do it, but this is one of the most ridiculously annoying things about the Flatpak sandbox. You can often only drag 'n drop from ~/Downloads/, and from any other location either causes the receiving application to glitch out, fail silently, or fail with a general error.…

Why? I am just asking for a simple UI, which Guix already has. Mainly for CLI applications. The idea is to be able to launch an ephemeral shell with any combination of packages, filesystem R/W privileges, and network access in a convenient way. I think launching e.g. a Python shell with some packages that are potentially compromised and letting those read ~/.ssh and whatever else they want is fundamentally insecure.…

An UI would be fine, but having no permission to access ~/ is a terrible default. It causes a lot of breakage and glitchiness because applications are simply not written with that limitation in mind. This is why Flatpaks often crap out. It will cause a huge amount of applications / binaries to crap out if it became the default in NixOS, and lord knows NixOS has enough sharp edges already.

The best solution would be a framework akin to macOS that pops up 'allow application X to access folder Y from now?' in the UI or in the CLI as a terminal prompt whenever an application tries to access a folder. With a special permission for "full home access" and "full disk access".

Re: NixOS and reproducible builds could have detected the xz backdoor

#113
post #13
post #5

Note that NixOS and reproducible builds did not detect the xz backdoor, and in fact NixOS shipped the malicious builds of xz (though they didn't do anything because the malware didn't target NixOS): > I am a NixOS developer and I was surprised when the backdoor was revealed to see that the malicious version of xz had ended up being distributed to our users. As always theory and reality are different, and the thing th…

> NixOS and reproducible builds did not detect the xz backdoor Nix declarativeness is quite useful to increase protection against exploits in a number of ways. Unfortunately, there is still a lot of untapped potential. My number one priority would be to implement fine-grained ephemeral containers. Guix has these already. This would make it convenient to run every single process with restricted privileges, including n…

>Still, I think the xz backdoor did not work on NixOS because its unusual non FHS-compliant filesystem structure.

It didn't work on NixOS because the build-time hooks that inserted the backdoor only activated itself when it recognized that it was being built for an RPM or Debian package.

Re: NixOS and reproducible builds could have detected the xz backdoor

#114
post #20
post #13

Earlier quoted context omitted.

> NixOS and reproducible builds did not detect the xz backdoor Nix declarativeness is quite useful to increase protection against exploits in a number of ways. Unfortunately, there is still a lot of untapped potential. My number one priority would be to implement fine-grained ephemeral containers. Guix has these already. This would make it convenient to run every single process with restricted privileges, including n…

You don’t even need to run in a container for this. It’s possible to do this entirely in systemd service configuration. The easiest way is just to have separate user for every service and reduce stuff running as root. You can also restrict filesystem access, network access and even syscall access (although some of this may be implemented as a container under the hood). Unfortunately, this wouldn’t help with the xz vu…

sshd was compromised, and it doesn't access private keys. (well, probably the host key.)

Re: NixOS and reproducible builds could have detected the xz backdoor

#116
Is the massive number of spam messages on this thread an attempt to suppress the article / discussion around it?

I've not seen this many from multiple but evidently related green accounts before. Given the implications about nation state actors in play, it's tempting to jump to conclusions here.

Re: NixOS and reproducible builds could have detected the xz backdoor

#117
post #44

llm commit scanning might be an interesting approach to the oss supply chain security problem.

Maybe, but good luck getting an LLM (one which does not include analysis of this particular attack in its training data) to spot this attack with a prompt that doesn't also create thousands of false positives when focused on the millions of non-malicious commits out there. I think we're decades away from them being that good.

Re: NixOS and reproducible builds could have detected the xz backdoor

#118
post #5

Note that NixOS and reproducible builds did not detect the xz backdoor, and in fact NixOS shipped the malicious builds of xz (though they didn't do anything because the malware didn't target NixOS): > I am a NixOS developer and I was surprised when the backdoor was revealed to see that the malicious version of xz had ended up being distributed to our users. As always theory and reality are different, and the thing th…

Right. The title seemed to be suggesting that the Nix way of doing things might have detected the backdoor. It's actually intending to suggest ways that Nix could be changed in order to detect the backdoor.

Re: NixOS and reproducible builds could have detected the xz backdoor

#119
post #116

Is the massive number of spam messages on this thread an attempt to suppress the article / discussion around it? I've not seen this many from multiple but evidently related green accounts before. Given the implications about nation state actors in play, it's tempting to jump to conclusions here.

It's multiple threads, not just this one, and it's been on and off the past few days.

You can add these kind of lines:

  news.ycombinator.com##tr.athing.comtr:has(a.hnuser:has-text('banana_dick'))
  news.ycombinator.com##tr.athing.comtr:has(a.hnuser:has-text('sirspamalot'))
to any uBlock or AdBlockPlus type extensions with manual compatible custom filters that you might have added to your browser.

> It's quite amazing that these new "green" accounts can post as many messages as they want while I'm being restricted

That's not what is happening .. look at the account names and the number of comments made by each.

Re: NixOS and reproducible builds could have detected the xz backdoor

#120
post #116

Is the massive number of spam messages on this thread an attempt to suppress the article / discussion around it? I've not seen this many from multiple but evidently related green accounts before. Given the implications about nation state actors in play, it's tempting to jump to conclusions here.

No, this has been happening for a few days now. Browse threads from the past week with showdead enabled and you'll see them.
Post reply on HN