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

181–190 of 192 posts

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

#181

Post by genewitch »

XorNot wrote: post #39
genewitch wrote: post #36

Earlier quoted context omitted.

This is by design do you can't exfiltrate data. Nix is so advanced I feel like a caveman with my openrc Gentoo.

I mean I could also just not use computers, or the internet and that would be perfectly secure as well. Breaking or making actively annoying expected and useful functionality isn't security (and has a long track record of leading to workarounds which compromise security).

Oh, i know. I was making a joke at Nix's expense, such that i fully expected to be downvoted for said joke, but i also expected some "nah-uh, that's not why;" and then a page of evangelism for NixOS, the one True™ OS.

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

#182

Post by johnea »

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…

> As always theory and reality are different

Thank you very much for citing that! along with highlighting the fact that the exploit was in fact, not detected by reproducible builds prior to other means of discovery.

In recent times, actual reality is often maligned when compared to how people feel about objective reality and how it meshes with their individual value systems.

I have personal values too, but I don't hold the opinion that actual reality is less significant than how I feel about it. It's not a popular perspective 8-/

I've always liked to say: The difference between theory and reality is that, in theory they're the same, and in reality they're not.

I hope the realization that the reproducible builds of NixOS _could_ have detected the xz exploit, but didn't, will lead to new advances in the analysis of those reproducible builds to detect other exploits sooner in the future.

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

#183

Post by a-dub »

yellowapple wrote: post #130
a-dub wrote: post #44

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

Commit scanning probably wouldn't have caught this, since the backdoor happened outside of any commit. Comparing the tarball's contents against the VCS repository would've likely made this easier to catch, but at that point you might as well just use the VCS repository directly.

i wonder if an llm could have spotted the malicious patches to autotools in the dist tarball...

a public, deterministic and assured build facility for oss would be cool. also maybe a deprecation of autotools.

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

#184

Post by account42 »

attila-lendvai wrote: post #178
brabel wrote: post #156

Earlier quoted context omitted.

A slightly improved version of any OS would've automatically caught it.

mechanism, or it didn't happen. and if any OS, then for windoze please!

if ( file_checksum == xz_backdoor ) { red_alert(); }

There.

Of course this doesn't buy you anything if the exploit is changed to target a "patched" OS but the same goes for the proposed Nix solution.

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

#185

Post by account42 »

brabel wrote: post #157
drpossum wrote: post #142

Earlier quoted context omitted.

[flagged]

In defense of the author: nobody reads your article if the name is boring (that is my experience at least), which it would've been if they titled it more accurately. That gives incentive to authors to use click-bait titles.

In defense of the bank robber: no clerk simply gives you money if you aren't threatening them (that is my experience at least), which it would have been if they acted like a respectable citizen. This gives people the incentive to become bank robbers.

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

#186

Post by account42 »

mkj wrote: post #137
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)

Autoconf releases are distributed as .tar.xz archives.

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

#188

Post by __MatrixMan__ »

chungy wrote: post #148
__MatrixMan__ wrote: post #136

Earlier quoted context omitted.

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…

> 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 That wasn't the highlight of the point. It was that you can restore to a known good version of the operating system, effortlessly, regardless of what the operating system is. It could be Ubuntu, Nix, or FreeBSD. Br…

I think that IT departments are going to disallow their users that kind of freedom unless they have more information/control about just which configs their users are allowed to boot to. It has to be more descriptive/composable than a pile of bits and a timestamp or they won't go for it at all.

As much as I want to put all the power in the hands of the user, I'm sympathetic to the plight of the IT guy who has a team that always boots to "last known good" config thats several years old because they just don't trust updates in general.

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

#189

Post by brabel »

account42 wrote: post #185
brabel wrote: post #157

Earlier quoted context omitted.

In defense of the author: nobody reads your article if the name is boring (that is my experience at least), which it would've been if they titled it more accurately. That gives incentive to authors to use click-bait titles.

In defense of the bank robber: no clerk simply gives you money if you aren't threatening them (that is my experience at least), which it would have been if they acted like a respectable citizen. This gives people the incentive to become bank robbers.

First of all: an exagerated title is in no way compared to threatening someone's life.

Secondly: your comparison does not even make sense: "which it would have been" what?? Try harder next time.

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

#190

Post by nextos »

jstanley wrote: post #149
nextos wrote: 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…

> including no access to ~/ This is such a headache with snap and flatpak though. If you're trying to do something that the package maintainer thought of in 5 minutes of testing then it's usually fine, but still inside any non-trivial application you'll often find parts that try to use extra privileges that aren't documented because they're not normally considered "privileges". Some examples of sandboxing issues: * F…

Firejail sandboxing works well on these scenarios. You can trivially grant more or less privileges, including the removal of the entire sandbox if you wish.

It actually ships with rulesets for hundreds of programs that tend to be quite polished and work out of the box.

Personally, I dislike flatpak because it doesn't let me control the dependencies of packaged software, and I feel we loose one of the most important advantages of Linux.

Post reply on HN