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

161–170 of 192 posts

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

#161

Post by jstanley »

fc417fc802 wrote: post #155
jstanley wrote: post #149

Earlier quoted context omitted.

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

You raise many good points. One of the primary reasons I don't use nix or guix for everything is because it seems like there's too much magic and it's often too difficult for me to figure out how to modify a detail if a toggle wasn't explicitly provided for it. Even just getting insight into the chain of events to debug things was incredibly obtuse the last time I played with nix. Like cmake on steroids. At least cma…

> That's an Inkscape (plugin?) bug plain and simple. GUI apps should be using the appropriate xdg portals

We can state what they "should" be doing until we're blue in the face, but if they "aren't" doing that then it doesn't help.

> Which client is this?

The Matrix one is from a long time ago. It could have been Element? Or Riot? Were they the same thing? Don't know. I only used it briefly.

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

#162

Post by johnisgood »

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…

I wonder how much it applies to Guix.

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

#163

Post by dist-epoch »

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…

The reason is a bit funny - the NixOS bootstrap downloads it's source code which is a xz compressed tarball.

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

#164

Post by johnisgood »

> the release tarball being different than the source is

> the maintainer provided tarball was honestly generated from the original source code.

How, then? What about differing versions, etc. or has it been mentioned and I just missed it?

Just make sure the generated tarball can be generated from the source code itself, do not exclude anything, git add & commit everything. Can't we do that? We would still have to look at commit history in this case, I believe, and again, he said it himself, it was harmless to the naked eye, so even then, how could we verify? Maybe I don't understand what he meant by verification, but if maintained tarballs are generated from the owner's source code and is not on GitHub (or anywhere else, just a git repo), that is a problem in itself.

Of course there was more to it than just pushing poisoned test files, but still. I do not see how Nix would have prevented it, if the git repo has those test files and with seemingly harmless code (and is reproducible).

Perhaps what we can do is: if an (in)famous project has changed its main lead, then pay closer attention to the commits and check who it is? I don't know, TBH.

Did I misunderstand the article, or am I missing something?

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

#165

Post by fc417fc802 »

dzaima wrote: post #135
massysett wrote: post #111

Earlier quoted context omitted.

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 "l…

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

There's also value in leaving a trail to make auditing easier in the event that an attack is noticed or even if there is merely suspicion that something might be wrong. More visibility into internal processes and easier UX to sort through the details can easily make the difference between discovery versus overlooking an exploit.

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

#166

Post by [deleted] »

__MatrixMan__ wrote: post #136
XorNot wrote: post #133

Earlier quoted context omitted.

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…

[deleted]

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

#167

Post by fc417fc802 »

jstanley wrote: post #161
fc417fc802 wrote: post #155

Earlier quoted context omitted.

You raise many good points. One of the primary reasons I don't use nix or guix for everything is because it seems like there's too much magic and it's often too difficult for me to figure out how to modify a detail if a toggle wasn't explicitly provided for it. Even just getting insight into the chain of events to debug things was incredibly obtuse the last time I played with nix. Like cmake on steroids. At least cma…

> That's an Inkscape (plugin?) bug plain and simple. GUI apps should be using the appropriate xdg portals We can state what they "should" be doing until we're blue in the face, but if they "aren't" doing that then it doesn't help. > Which client is this? The Matrix one is from a long time ago. It could have been Element? Or Riot? Were they the same thing? Don't know. I only used it briefly.

> if they "aren't" doing that then it doesn't help.

True enough. To be clear I don't fault anyone for not using new or known to be broken or little known standards.

However at some point responsibility has to shift to the developers. There are standard ways of doing things. Just as you can't expect an arbitrary project to support your pet API that hardly anyone uses, developers can't expect major distributions or the majority of users to cater to their refusal to conform to widely accepted standards.

I'm not saying you shouldn't use a particular program. Just that I don't think it's reasonable to fault the tooling for certain things.

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

#168

Post by johnisgood »

dralley wrote: post #113
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…

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

Which could have been adjusted, of course.

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

#169

Post by [deleted] »

ratorx wrote: post #30
nextos wrote: post #25

Earlier quoted context omitted.

> It’s possible to do this entirely in systemd service configuration Sure, but I think that leaves out many use cases. What if I want to e.g. start a Python shell that has access to certain directories, and nothing else, including no network access? Nix provides a good way of doing that for common use cases, as it has decent support for Firejail. But I would like something like Guix containers, which is convenient fo…

Yeah, I guess most existing Linux stuff that is actually configured (so not SELinux etc) is geared at system processes not user ones. Transparently running all user applications in properly isolated containers would be quite neat. Does Firejail handle dynamic access (eg. I may want an xz invocation to work on my private keys, but not THIS specific one where I’ve given it a completely different file?). I quite like pl…

[deleted]

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

#170

Post by microtonal »

fc417fc802 wrote: post #158
gf000 wrote: post #153

Earlier quoted context omitted.

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.

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 their sandboxes, the same applications have much more limited privileges nowadays.

It's a long process, but at least with desktop applications there is progress. Unfortunately, the same can't really be said about command-line tools and development tools (NPM, cargo, pip, editor plugins, etc.).

Post reply on HN