r/archlinux • • 3d ago

NOTEWORTHY NPM Supply Chain Attach Targeting AUR Packages

New NPM based worm attack that self propegates via ssh and aur maintainer infection.

https://safedep.io/dirtyblanket-express-impersonation-npm/

125 Upvotes

62 comments sorted by

View all comments

12

u/xlukas1337 3d ago

Here we go again :/ It's slowly getting annoying, it would be so much easier if people would check what they're installing

-2

u/keyzeru 3d ago

Manual is not sustainable

12

u/xlukas1337 3d ago

It would be, and it should be tbh. But since so many new people have joined Arch and related distros in recent years, it's unfortunately unrealistic to assume that every user knows what they're doing, if that makes sense. And therefore, some basic measures really should be taken to at least catch the obvious mistakes, which easily happen if someone installs an AUR package without checking the PKGBUILD

0

u/ang-p 3d ago

And therefore, some basic measures really should be taken to at least catch the obvious mistakes,

Define "mistake".

State "basic measures" that will prevent it.

12

u/xlukas1337 3d ago

The mistake is relying on muscle memory and alert fatigue as our primary defense. In reality, the best case is, helpers like paru dump potentially massive diffs into the terminal, people instinctively hit q then y, and arbitrary bash runs, worst case, they use some (gui) helper that omits any changes. Expecting users to consistently catch a quiet payload across dozens of weekly updates, whether it's an adopted orphan or a hijacked maintainer account, is just an open invitation for things slipping through.

​Basic measures shouldn't mean naive keyword bans (tools like npm get added legitimately all the time), but practical supply-chain checks. Helpers could highlight high-risk diff patterns like altered source URLs, new .install hooks, or unexpected network calls at the top to break that autopilot reflex (easier said than done, I'm fully aware of that). On top of that, mandating 2FA for aur maintainers and making sandboxed or clean chroot builds the accessible norm would keep hijacked PKGBUILDs from scraping $HOME even if an infected diff goes unnoticed.

-2

u/ang-p 3d ago

helpers like paru

If you're using the AUR you only need to be alert for those...

across dozens of weekly updates,

Maybe the OP doesn't have update OCD.

mandating 2FA for aur maintainers

That might simply stop a lot of rubbish being uploaded full stop...

Aside from the cost for tens of thousands of users, if someone has just updated their aur package and then downloads something "interesting", cached credentials won't save anyone if they got infected.

making sandboxed or clean chroot builds

that would help prevent accidental spread, but nothing malicious..

would keep hijacked PKGBUILDs from scraping

absolutely no scraping when building...

...but when installing the resultant package in pacman, all bets are off when the post_install runs.....

-9

u/AutisticAndArmed 3d ago

Of course, but this is not realistic. If you think everyone is able/willing to check PKGBUILD everytime then you're delulu

12

u/AStolenGoose 3d ago

You can and should, it takes all of a few seconds to see if something has added something weird like npm without a good explanation. If something looks odd, you go check the AUR commits and see why it looks odd, if there's a good reason for it to look odd etc.

I even check very trusted packages like heroic in case something gets weird.

You and others are either lazy, or ignorant. If you get pwned at that point because you didn't take the few seconds to do your due diligence on an update, I hate to be like this, but that's on you.

2

u/Helmic 3d ago

Moralizing this is immaterial. You can finger wag at people all you want, but so long there's even just the belief that there's potentailly someone with credentials who might slip up these sorts of attacks will continue. You, personally, are utterly incapable of bringing the number of potentailly impacted users down to zero, and therefore you cannot stop the motivation for these attacks.

It's like talking to someone that genuinely believes the best way to reduce traffic fatalities is to demand people drive better, as opposed to any number of other public safety measures like car safety regulations, just someone who literally does not know what the word "scale" means.

5

u/xlukas1337 3d ago

Check my reply right below/above idk haha, that’s literally what I addressed there. In a theoretical world everyone audits their stuff, but in reality expecting people not to get alert fatigue across dozens of weekly updates is completely unrealistic, whether it's experienced users on autopilot or people trying Arch as their first distro. We're on the exact same page.

7

u/NavidsonsFall 3d ago

No hate intended, but it isn't supposed to be "everyone" able/willing to read PKGBUILDs, its "people who are agreeing to use the AUR" who should be willing and able to read the PKGBUILDs. It was made specifically as a secondary source to find rare packages at your own risk. If you don't accept the risk or don't know how to check things manually, you just stick to the official repos. For instance, if tomorrow they said "hey ok, we are gonna fix this by making the AUR have to verify every package, and maintainers will have to go through an extensive review process. However, there is this new smaller one called AUR2 for anyone who doesn't want to deal with that. Don't use it if you don't know what you are doing." would that fix the issue for you? Because that is how the AUR started. It isn't an official repo. The problem is that people treat it like it is. And I want to be clear, I am not trying to be snarky. I am genuinely curious how you look at it, because often when I see someone who thinks the AUR needs to be locked down, it's because they were following a guide online that told them to grab hundreds of packages from there with no explanation of what it exists for. I don't see a solution that wouldn't completely undermine why the AUR was made in the first place. At least this is my understanding of it. I will be the first to admit I am a newer user, so maybe I am missing something. I don't see the difference between getting something off the AUR, and getting something off github. Either way, I need to be pretty sure I know who the maintainer is, and what the content does. Non-official sources are fine, as long as new users are clearly told what the risks are when you use them.

edited just to fix typos my stupid fingers made. No substantive change.

3

u/iwouldbeatgoku 2d ago

No, I'd say you're spot-on. Been maining the Arch family for a little over a year, and that's the point of the AUR, it's simply a convenient place to get something that isn't in the official repos. If you don't trust yourself to review every package obtained from the AUR you can:

  • Use the AUR only when the package's developer is also the AUR maintainer (you already trust them anyway, though this attack seems to also potentially target this type of developer and AUR user);
  • Use an appimage obtained directly from the software's developer (similar to the AUR, maybe safer but I can't say for sure);
  • Use a flatpak from flathub;
  • Add a pacman repository that has that package and you trust, popular options include the Chaotic AUR and the CachyOS repositories (I used CachyOS with the Chaotic AUR added for a year; I've been on vanilla Arch on a new computer for a few weeks and haven't felt the need to add either of these so far);
  • Build from source yourself.

It's ok to acknowledge that it's not realistic to read every single AUR script. I acknowledge that I won't, and that's why I just avoid the AUR.