Is nixpkgs (potentially) susceptible to deps malware recently discovered in AUR?

1

As many of you probably already know, there was a recent discovery of malware distributed through npm dependencies in several AUR (Arch User Repository) packages. A good preliminary analysis of its behavior can be found in this blog post.

As a former Arch user who migrated to NixOS about a year ago, this discovery has made me wonder whether nixpkgs could be susceptible to a similar attack in the future, and more generally about the security aspects of NixOS compared to other distributions. If possible, I’d appreciate it if more experienced users could help clarify a few questions:

  1. Would malware of this kind still be effective on NixOS system (featuring a read-only Nix store)?
  2. Does the isolation between packages and dependencies provided by Nix affect this type of vulnerability in any meaningful way?
  3. Assuming a similar incident were to occur in Nixpkgs, what would be the most likely fix from upstream? (My first guess would be to sanitize all affected packages and rebase all the commits that reference them).
  4. What would be the most effective remediation for an end user? Would a simple update followed by nix store gc be sufficient, or would a full reinstall be recommended?
  5. Are there any additional modules or configuration options that could help reduce the attack surface? For example, would an impermanent setup that wipes / on every reboot provide any meaningful protection or limit the malware’s persistence?

Thank you in advance for helping clarify my doubts! :grinning_face_with_smiling_eyes:

2

Not exactly. The problem that was exploited with the AUR is that there is no oversight over the packages whatsoever. Anyone can pick up a package without a maintainer and modify it.

See also the warning on their homepage:

DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk.

This has been an exploit waiting to happen for a good 15 years. It has been happening on smaller scales, actually, there’s just clearly some script kiddie who decided to wage war now.

That said, a similar attack with a bit more social engineering against nixpkgs is doable. Nixpkgs is simply far too big - theoretically people with the commit bit are supposed to review every change, but I can imagine a world in which someone starts generating GitHub accounts with an LLM and submits correct-looking enough patches at scale.

It’s more difficult, though.

As for the actual binary being deployed, all of that doesn’t really matter, a successful supply chain attack has all the power it wants. No technical measures can protect you.

Well, mostly...

There is some degree of hardening in NixOS services thanks to systemd. This kind of exploit would need to be performed against a package that doesn’t have any sandboxing, or lifting of the sandboxing would have to be applied sneakily enough that a committer doesn’t notice.

So there is some protection in the sense that NixOS makes it hard to sneak by blatant malware. Credential stealers like the AUR one are however still really easy, since most software ultimately needs to be executed by your user (flatpaks are a theoretical solution, but flatpak sandboxes tend to be very leaky).

In any case, all of this just boils down to the likelihood of success of the supply chain attack. Once the hypothetical malware is in nixpkgs, it can be expected to function as intended.

There’s not much you can do to prepare for such an attack, except try to review all changes that make it into nixpkgs.

5 Likes
3

If i think i have a virus i always reinstall. As nixos makes a reinstall especially easy just reinstall. The annoying part will be to rotate ssh keys and passwords.

1 Like
4

It depends on the malware deployed. Sometimes this is not sufficient, rootkits exist.

Follow guidance that people give you when the exploit is discovered, this is very case-by-case. A full wipe and rotating all exposed credentials is generally advisable, though (and nix store gc is definitely not a solution).

2 Likes
5

The bigger risk with nixos imho is malicious changes in the upstream repos. Malicious changes in nixpkgs are possible of course too, either by managing to getting something merged or by infiltrating a trusted community member with commit access, but not with nearly as much ease as AUR where anyone can just sign up and create or claim packages with zero oversight.

4 Likes
6

In fairness, past supply chain attacks of this form (e.g. xz) didn’t directly target NixOS, and usually failed because NixOS is weird.

With increasing popularity I suspect we’re becoming a target to explicitly add support for, though, and “malware authors have to write idiomatic code to hit us” was always a brittle defense to begin with.

5 Likes
7

I have to admit the idea of opening PRs to the repo of some exploit kits to get them to support NixOS has crossed my mind before.

2 Likes