Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AUR packages compromised with Infostealer and Rootkit

discourse.ifin.network

Post reply on HN
Print view View original

131–140 of 234 posts

Re: AUR packages compromised with Infostealer and Rootkit

#131

Post by gqgs »

Tharre wrote: post #68

People need to get into their heads that the AUR is just a collection of user-produced PKGBUILDs. You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates. This really has always been the case; we've had discussion about this for well over a decade. People are always asking why there's no official AUR helper like yay - this is why. A lot of people complain abo…

Regardless of it being just a collection of user-produced PKGBUILDs the community would certainly benefit from a more robust solution to this issue.

Expecting users to manually review every single change, for every single AUR package they are using, every single time they do an update or installation is just unreasonable if you want to AUR to be useful at all for the general user.

Re: AUR packages compromised with Infostealer and Rootkit

#132

Post by Tharre »

hypfer wrote: post #129
kpcyrd wrote: post #128

Earlier quoted context omitted.

The server actually hosting the rootkit executable is npmjs.com, run by a for-profit company, and they still take about 24h to act on our reports, while reported AUR packages have been processed in about 1-2h by people that work unrelated dayjobs on top of this, to self-subsidize their open source work. Sorry you're displeased with us not writing blogposts faster on top of all this. The situation is already exhaustin…

Look, man, I understand all that, but pulling the plug is something that takes at most 90s. Let's say 300s to add the "Warning: There is an attack. We're working on it. Systems are down for now" box After that, you have all the time in the world to prioritize dayjobs etc. It's not about dropping everything and fixing the root cause. It's just about taking stuff offline so that the immediate danger is mitigated. That…

"Hey, let's take down all of npm, because there's a package that installs something malicious, and some people may install it without reviewing it first. The thousands of other people relying on this service can wait."

Do you not realize how crazy of an request that is?

Re: AUR packages compromised with Infostealer and Rootkit

#133

Post by hootz »

ptx wrote: post #126
hootz wrote: post #62

Earlier quoted context omitted.

For every single update, for all your AUR packages, all the time. You know that thing where if you make a security review feature obnoxious, after some time people will just accept everything without even looking? Yeah...

> For every single update, for all your AUR packages, all the time. Yes, that's what I used to do when I ran Arch. It's usually easy. The PKGBUILD is usually small to begin with and the difference for a new version should normally be something like the URL and the version number and not much else, so you can just diff it against the old version.

I do it too, but I can see why this can be a problem for users. There should be an "official" scan for potentially malicious changes. I use a third party AUR scanner to help me with this.

Re: AUR packages compromised with Infostealer and Rootkit

#134

Post by Foxboron »

gqgs wrote: post #131
Tharre wrote: post #68

People need to get into their heads that the AUR is just a collection of user-produced PKGBUILDs. You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates. This really has always been the case; we've had discussion about this for well over a decade. People are always asking why there's no official AUR helper like yay - this is why. A lot of people complain abo…

Regardless of it being just a collection of user-produced PKGBUILDs the community would certainly benefit from a more robust solution to this issue. Expecting users to manually review every single change, for every single AUR package they are using, every single time they do an update or installation is just unreasonable if you want to AUR to be useful at all for the general user.

> Expecting users to manually review every single change, for every single AUR package they are using, every single time they do an update or installation is just unreasonable if you want to AUR to be useful at all for the general user.

How many AUR packages are you assuming people are installing?

Re: AUR packages compromised with Infostealer and Rootkit

#135

Post by porridgeraisin »

Tharre wrote: post #105
tetromino_ wrote: post #100

Earlier quoted context omitted.

> I'm not sure what the alternative would be, reviewing every adoption request seems like too much effort and wouldn't necessarily even help every time. Even the most primitive LLM review workflow would have caught this compromise. Adding or modifying any invocation to a PKGBUILD that may download something from the network and execute it (whether using npm, pip, curll|bash, or whatever else) -> automatically quarant…

Any and all modifications to PKGBUILDs may download something and execute it, that's the very purpose of PKGBUILDs, to download and install new software. I'm sure it would be great to have trusted reviewers look over every update, but the simple reality is that all of this work is done by volunteers and there isn't nearly enough manpower for it. Maybe doing automated LLM reviews would help, but this is a large infras…

I have LLM operate yay on my machine before installing and read PKGBUILDs and summarise it for me and I look through the weird ones and only then do the actual upgrade. Maybe we can make an aur helper that is wired up to deepseek :D

Re: AUR packages compromised with Infostealer and Rootkit

#136

Post by tetromino_ »

Tharre wrote: post #105
tetromino_ wrote: post #100

Earlier quoted context omitted.

> I'm not sure what the alternative would be, reviewing every adoption request seems like too much effort and wouldn't necessarily even help every time. Even the most primitive LLM review workflow would have caught this compromise. Adding or modifying any invocation to a PKGBUILD that may download something from the network and execute it (whether using npm, pip, curll|bash, or whatever else) -> automatically quarant…

Any and all modifications to PKGBUILDs may download something and execute it, that's the very purpose of PKGBUILDs, to download and install new software. I'm sure it would be great to have trusted reviewers look over every update, but the simple reality is that all of this work is done by volunteers and there isn't nearly enough manpower for it. Maybe doing automated LLM reviews would help, but this is a large infras…

> Any and all modifications to PKGBUILDs may download something and execute it

A normal PKGBUILD should not download anything programmatically. It should rely on the package manager to download the files listed in the PKGBUILD's source array. If a PKGBUILD is running a command to download something not listed in source, that's a sign that something nefarious could be happening, and such a PKGBUILD absolutely requires careful human review.

> all models are quite vulnerable to prompt-injection type attacks

A less than 100% reliable mechanism sure beats the current situation which is "wait for users report on the forum that they have been pwn3d". May I remind that this is the third time AUR-hosted PKGBUILDs have been compromised?

Re: AUR packages compromised with Infostealer and Rootkit

#137

Post by hypfer »

Tharre wrote: post #132
hypfer wrote: post #129

Earlier quoted context omitted.

Look, man, I understand all that, but pulling the plug is something that takes at most 90s. Let's say 300s to add the "Warning: There is an attack. We're working on it. Systems are down for now" box After that, you have all the time in the world to prioritize dayjobs etc. It's not about dropping everything and fixing the root cause. It's just about taking stuff offline so that the immediate danger is mitigated. That…

"Hey, let's take down all of npm, because there's a package that installs something malicious, and some people may install it without reviewing it first. The thousands of other people relying on this service can wait." Do you not realize how crazy of an request that is?

You do realize that the people relying on the service also get served wormable malware, right?

The service is already disrupted. It is not that a disruption could be _avoided_. The discussion makes no sense.

___

Hell, even if I would be completely wrong in that assessment (not sure how, but let's assume that's the case)

You can still put up a banner. "Hey, FYI: We're under attack".

If not right away, then at the very least the moment media reports on it. And if media reported wrong, the banner says "Don't worry people. Media got it wrong."

Re: AUR packages compromised with Infostealer and Rootkit

#138

Post by sandreas »

porridgeraisin wrote: post #127
sandreas wrote: post #125

So, could anyone sum up the "Am I owned" part of the problem to check which measures to take? AFAIK I'm pretty likely owned if all of this is true: - The following line shows at least one affected package: echo "Affected Packages Found:"; comm -12 - I updated AUR in the last 24 hours If I did not update AUR, in the last 2 days, it should be ok (at least for this specific problem). If I don't see affected packages fro…

Nothing is necessary if you didn't update AUR packages over the last 2 days. If you wait a day further, the maintainers will cleanup these as well, after taht you can upgrade.

Allright, sounds like I'm lucky. Thanks for clearing this up.

Re: AUR packages compromised with Infostealer and Rootkit

#139

Post by Matl »

DavideNL wrote: post #130
codemac wrote: post #116

Earlier quoted context omitted.

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

Curious, in this specific case: if people DID review the PKGBUILD, what exactly would they recognize to spot these packages were compromised ?

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

Re: AUR packages compromised with Infostealer and Rootkit

#140

Post by weaksauce »

DavideNL wrote: post #130
codemac wrote: post #116

Earlier quoted context omitted.

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

Curious, in this specific case: if people DID review the PKGBUILD, what exactly would they recognize to spot these packages were compromised ?

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.
Post reply on HN