Malicious Atomic Arch NPM Campaign Thread

brokenwing@discuss.tchncs.de · edit-2 18 hours ago

Malicious Atomic Arch NPM Campaign Thread

jwt@programming.dev · 9 hours ago

Not a dig at you or the script author, but I’m kinda miffed we’re relegated to running some rando github user’s bash scripts to check if we’re affected. This is the direct opposite response one should have to this kind of attack. I feel the AUR maintainers should have been more forthcoming about what they are doing to stop the attack and how users can mitigate the consequences if affected.

brucethemoose@lemmy.world · 9 hours ago

That was my immediate reaction, too. And “why did I only find out on Lemmy!?”

AUR is hosted on archlinux.org, after all.

…But to be fair, the AUR was always “use at your own risk.” Its PKGBuilds are supposed to be manual scripts, not automated with yay/paru. But still, it’s ultimately malware hosted on Arch Linux’s domain, though a huge security hole (the two week orphaned package thing).

Its possible my downstream distro (CachyOS) sent some kind of alert through pacman or published some utility, but I am away from my desktop until tonight, so I haven’t checked in a while.

Tetsuo@jlai.lu · 8 hours ago

How else would you have wanted to be warned ?

In my opinion that’s the other side of the privacy coin.

What happens on my system is only for me to check. And in that case that means I’m on my own to be aware of its current state.

I mean the cachyos devs or the AUR maintainer have in some way by design no way to reach me. And creating some kind of malware monitoring or scanning tool included by default would be against the ethos of the OS…

So it’s up to each user to determine if they want to use random scripts or just read the blog of their OS and do everything manually. There isn’t an adequate universal solution there.

brucethemoose@lemmy.world · 8 hours ago

Notifications for individual package updates do come through pacman. They could also put a checking tool into CachyOS Hello, which is shipped and pops up by default.

And I’ve definitely gotten “urgent” text notifications that all-but-required manual action through pacman.

I do generally agree with you though. The responsibility to pay attention is on the user with Arch. It’s part of the contract, and why it isn’t for everyone.

Tetsuo@jlai.lu · 5 hours ago

They could also put a checking tool into CachyOS Hello, which is shipped and pops up by default.

What would this “checking tool” look like? What would it check?

I personally have deactivated the opening cachyos Hello a long time ago. Why would I need that popup once I setup everything?

And I’ve definitely gotten “urgent” text notifications that all-but-required manual action through pacman.

Pacman has no idea if it is installing something malicious. It notifies you only on functional actions that are required.

Basically, none of the suggestions you make would have avoided the AUR attack to work. Nor a future one?

The only thing I would maybe agree is for some notification system that let’s the cachyos maintainers send an urgent message but that would mean they would have to sign that message in some way. If that signature verification ever fails someone could send malicious notifications to all cachyos users and that would create another threat.

And even then if the malicious package is noticed after a few days, if you already installed/updated it, it’s too late. You could receive a notification giving guidelines to cleanup but that’s too late. The infection could disable these notifications or worse.

And if you have an emergency notifications systems, is it a “pull” or “push” notification? Is it your computer that checks if there is a notification? How long between pulls? If that’s a push then the notification servers basically has a full list of cachyos IPs which would suck too.

Sorry if I look nitpicky but I just want to illustrate that this is a very very complex problem to solve while respecting user privacy and “sovereignty” over their system. Supply chain attacks are extremely difficult to defend against and open source projects have increasingly numerous dependencies…