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

171–180 of 192 posts

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

#171

Post by microtonal »

xp84 wrote: post #128
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…

I get the potential need for such draconian measures in perhaps, some top secret government installations or something, but gosh that sounds tiring -- a lot like MacOS lately asking me "(AppName) wants to access your Downloads folder, cancel or allow?" when I have just directed it to open a file.

Even if you only use trusted applications and they have stringent security policies avoiding supply chain compromises, RCEs are a fact of life. E.g. iMessage vulnerabilities are found all the time and there are probably a lot of vulnerabilities that are not reported because state actors hold on to them. This is the reason why iOS uses application sandboxing and on top of that Blastdoor for iMessage.

Maybe Linux isn't as effected now because it is not very popular as a desktop system. But this issue will have to be addressed as/when Linux becomes more popular. Having networked clients that do image parsing, etc. (usually in C code) without any sandboxing will just lead to mass exploitation, data exfiltration, etc.

The Linux desktop has to move away from the 90ies security model where the internet was relatively safe and attackers would only be after UID 0.

a lot like MacOS lately asking me "(AppName) wants to access your Downloads folder, cancel or allow?" when I have just directed it to open a file.

I don't think it asks that when it goes through a portal (e.g. file dialog)?

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

#172

Post by yarekt »

massysett wrote: post #41

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.

Your comment doesn’t quite make sense: Building from source lets you (and everyone else) inspect the source, while building from provided tarballs means if you compare it to source it’ll be inherently different, as the autoconf process makes changes to the files.

If you’re downloading and executing a binary from github releases, then you’re completely at the mercy of the maintainer (nix only does that with closed source packages)

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

#173

Post by gsliepen »

While NixOS goes a bit further with it, most other distrubtions also compile everything from source, cryptographically verify that the sources they use are not tampered with, and have versioned dependencies between packages. Debian also has reproducible builds.

The problem is just that the build systems did not strip pre-compiled object files before building from source. Even with that fixed, if nobody checks the source code then you can add all the backdoors you want, and there is nothing in NixOS or any other distro that would protect against that.

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

#175

Post by fc417fc802 »

microtonal wrote: post #170
fc417fc802 wrote: post #158

Earlier quoted context omitted.

The usual answer in Android is "you can't do that". The primary difference from my perspective is that developers for those platforms design with the limitations in mind. Stuff on linux often just breaks and requires involved workarounds if it wasn't intended by the developer to be stuffed into a flatpak. (And might not even compile under nix without half a dozen monkey patches to the build system, let alone run once…

I think developers of desktop application are generally open towards facilitating sandboxing though. Most applications use standard XDG folders for files, use standard toolkit file pickers, etc. I don't have hard data, but my impression is that the general tendency in Flatpaks is that they are able to do more sandboxing over time. When Flatpak was new, a lot of applications pretty much required completely opening the…

I'm not even sure what it would look like for CLI tools. Probably the sanboxing tools themselves need better controls and better UX for those controls.

For CLI a solution would probably look a lot like unshare or (a more user friendly version of) setcap. The user would need to reach out to the sandbox to communicate what additional things to permit during this specific session.

And then inevitably someone would configure the equivalent of passwordless sudo at which point I wonder what the point of the whole thing was to begin with. Related, we need a better paradigm for CLI to differentiate between user versus programmatically generated input. A program shouldn't be able to impersonate me unless I explicitly granted it some extremely unusual privileges.

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

#177

Post by fsflover »

gf000 wrote: post #153
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…

Such sandboxes would only work well , if the whole OS would be built around supporting them. You would essentially need Android or iOS for it to not be a pain in the ass Nonetheless, in this year and age this should be the bare minimum from a security point of view.

> Such sandboxes would only work well, if the whole OS would be built around supporting them.

This. Which is why I'm using Qubes OS designed around sandboxing, and I can't recommend it enough.

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

#178

Post by attila-lendvai »

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

Earlier quoted context omitted.

a slightly improved version of NixOS (or Guix) would have automatically caught this backdoor once it reached their repos. they are relevant.

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!

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

#179

Post by dezgeg »

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…

autoconf itself doesn't need xz, but in Nixpkgs xz is part of the stdenv, meaning essentially every package has a build-time dependency on xz.

For the case of xz not using the upstream-generated configure would probably be doable with some effort but doing the same for glibc, gcc, gnumake etc. would be much more difficult.

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

#180

Post by mid-kid »

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…

> 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 check included checking whether the build was being executed in a debian or fedora build environment. This was to avoid suspicious build failures on distros with weird toolchains or incompatible architectures/ABIs/library versions. (The backdoor was a precompiled .o file so rather ABI sensitive)

Post reply on HN