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

NixOS and reproducible builds could have detected the xz backdoor

luj.fr

Post reply on HN
Print view View original

131–140 of 192 posts

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

#131

Post by conradev »

nextos wrote: post #13
lolinder wrote: 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…

The maintainer would just change the sandboxing constraints to weaken the software. Just like they did in the first place. You can try to make obfuscation difficult, but it’s always possible.

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

#133

Post by XorNot »

__MatrixMan__ wrote: post #89

If we want to focus on a thing that NixOS could have prevented, we should focus on the CrowdStrike incident. Being able to boot to yesterday's config because today's config isn't working would've mitigated most of the problems.

Except that's a Windows thing where you don't have boot flexibility.

Ubuntu on ZFS can do this as well.

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

#134

Post by ggggrah »

I think it's a vuln to think of OSS in terms of 'a community'. It's an abstract thought construct that does not represent reality (though it helps to make sense of it in a rather specific manner) xz happened because of the absence of community. It could happen inside this abstract thought of a community as well but here it did not.

xz targeted deb and rpm. The vast majority of what is facing the world.

Nix did not stop it.

I believe this article feeds the possible vuln rather than prevent it.

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

#135

Post by dzaima »

massysett wrote: post #111
dwheeler wrote: post #60

Earlier quoted context omitted.

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…

Might not be a big chance depending on the project in question, but it's still tons more likely for someone randomly clicking through commits to find a backdoor committed to a git repo than within autogenerated text in a tarball. I click around random commits of random projects I'm interested in every now and then at least. At the very least it changes the attack from "yeah noone's discovering this code change" to "let's hope no random weirdo happens to click into this commit".

A binary blob by itself is harmless, you need something to copy it over from the build env to the final binary. So it's "safe" to ignore binary blobs that you're sure that the build system (which should all be human-written human-readable, and a small portion of the total code in sane projects) never touches.

That said, of course, there's still many options for problematicness - some projects have commit autogenerated code; bootstrapping can bring in a much larger surface area of things that might copy the binary blob; and more.

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

#136

Post by __MatrixMan__ »

XorNot wrote: post #133
__MatrixMan__ wrote: post #89

If we want to focus on a thing that NixOS could have prevented, we should focus on the CrowdStrike incident. Being able to boot to yesterday's config because today's config isn't working would've mitigated most of the problems.

Except that's a Windows thing where you don't have boot flexibility. Ubuntu on ZFS can do this as well.

My point is that the lack of boot flexibility caused a lot of problems. If we want to be able to rely on people to get the job done even on days when something is wonky in the bits, then we should give them boot flexibility. NixOS just happens to do it especially well.

As for ZFS... Dealing in filesystem snapshots is comparatively a bit awkward. If you want to recreate that config elsewhere you have to move the whole snapshot rather than just the recipe for building it, and even then it'll break if the system architecture is different on the target machine. If you've got two of them (perhaps labeled "good" and "bad"), you're not going to get anything friendly when you try to diff them, nor is there an obvious way to use things like `git bisect` to reason about where the problem occurred.

None of these things are show stoppers, but working with code that defines some state is just so much easier than anything you get out of a filesystem which happens to remember that state, but can't tell you why it should be the way it is.

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

#137

Post by mkj »

dataflow wrote: post #100

Why is nobody questioning this: > To build xz from sources, we need autoconf to generate the configure script. But autoconf has a dependency on xz! Both directions of this seem crazy to me. 1. Why the heck should a build configuration tool like autoconf be unable to function without a compression tool like xz? That makes no sense on its face. 2. For that matter, why the heck should xz, a tool that is supposedly so fu…

I'm fairly sure xz _isn't_ a general dependency of autoconf etc. Some projects might use xz in their tests, but thats a general bootstrapping problem for xz, not autoconf.

(Autoconf is a pain and I would try to avoid for new projects, but for detecting all kinds of crazy old unices I'm not sure what is better)

Post reply on HN