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

151–160 of 234 posts

Re: AUR packages compromised with Infostealer and Rootkit

#151

Post by streb-lo »

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.

paru presents all pkgbuild diffs to you before installing, that's what I use to read them.

I usually only use AUR to install trusted pre-compiled binary packages, the scripts are very simple and the only thing that should ever change is the url and the sha256

Re: AUR packages compromised with Infostealer and Rootkit

#152

Post by backscratches »

dsp_person wrote: post #123
kpcyrd wrote: post #89

Earlier quoted context omitted.

This is an "in addition to" problem though, not an "instead of" problem. Having code reviewed the PKGBUILD doesn't mean the upstream software is safe to use, having reviewed the upstream software and it's dependency tree doesn't mean the PKGBUILD is safe to use.

Also have realized at some point that reviewing the PKGBUILD and code in github repo still doesn't check whether the github release files are compromised.

Build it yourself or bust

Re: AUR packages compromised with Infostealer and Rootkit

#153

Post by Tharre »

tetromino_ wrote: post #136
Tharre wrote: post #105

Earlier quoted context omitted.

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…

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

First, although I don't disagree with that being how it should work, in a world where everyone relies on npm, cargo, etc. to handle dependencies this scenario is not realistic.

Second and more importantly, it doesn't really change much if it's listed in the sources or not. You can patch a startup file to download something as soon as the program is executed, including checks if it's currently running in a virtual environment. You cannot statically detect that the PKGBUILD contains something like that, antivirus software has been trying to do just that for decades and their detection is still basically useless.

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

The current situation is users are expected to review PKGBUILDs before they install them. And you're ignoring that implementing any mechanism has a cost. I don't know if it's worth it or not, but it's not unrealistic that it would be a ton of effort for no barely any gain.

Re: AUR packages compromised with Infostealer and Rootkit

#154

Post by megous »

animitronix wrote: post #34

Wow, this is effectively the end of the AUR model. There's been a malicious package or two before, but an attack this widespread shows things are fundamentally broken. Guess I'll be switching to a new OS this weekend across multiple machines.

It's about as much an end of AUR, as we've seen an end of npm from its many decades of similar security/trust failures.

Re: AUR packages compromised with Infostealer and Rootkit

#155

Post by hypfer »

Tharre wrote: post #146
hypfer wrote: post #137

Earlier quoted context omitted.

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…

> You do realize that the people relying on the service also get served malware, right? The service is already disrupted. Huh? No they don't. I'm not sure what part of the attack your misunderstood, but most people are going to be completely unaffected by this. None of the infrastructure or anything like that got compromised. I updated my AUR packages 2 hours ago, and didn't get served any malware. Again, there's pro…

As said, I don't think discussing this makes sense, as our perceptions of reality seem to be fundamentally incompatible.

But regardless, let's try a different perspective: PR/Public perception

The moment multiple well-known media outlets start publishing a story stating that "stuff is happening", the situation changes.

At that point, regardless of how you personally feel about this, the narrative is "people are affected".

This forces your hand. Which is not(!) to say that it would mean that you would have to accept what the media says. The media could be full of shit talking nonsense. *But* at that point, you need to either correct them, or do the correct action as per their narrative.

____

I don't think that PR/Public perception is the main relevant perspective here - in fact I'm just mentioning it, because all the much stronger much more technical arguments seem to be lost on you.

But there you go.

Your argument makes no sense, because "ackschually I'm unaffected" is just russian roulette survivorship bias, but even if it _would_ make sense, the system logic of the next outer layer cans that take.

____

Anyway. The fact that people (not just you, mind you) are so busy playing "well ackschually" while there is an active wormable attack going on is precisely why I said "institutional rot". Although, I think I need to correct that to "cultural rot".

Priorities are broken. The wrong metrics are being optimized here.

I would love to hear more about this from the actual Arch maintainers instead of random users with opinions, but.. not sure where that communication would be. I didn't find any. And I did go looking!

___

Edit 50m later:

https://archlinux.org/news/active-aur-malicious-packages-inc...

Thank you!

Re: AUR packages compromised with Infostealer and Rootkit

#156

Post by jolmg »

Vexs wrote: post #82
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…

> You have to review the source of every PKGBUILD from the AUR you install, full stop I don't really think this is a solution- the usual workflow for these attacks has been to hide your payload in some dependency. This one is somewhat unusual in that it's just a very lazy `npm install` in the pkgbuild. Pretty much every package repository even outside of AUR has this issue now, and it's not really viable to audit the…

> it's not really viable to audit the entire dep chain by hand

When you `makepkg -s`, makepkg will get the dependencies it can from the vetted and maintained pacman repos. Only the dependencies that are not present there would have to be obtained from the AUR the same way as the package you're currently reviewing: git clone, manually review, makepkg, etc.

Having dependencies in the AUR is not that common in my experience. I think I've had rarely 1 or 2 deps in the AUR; maybe once or twice I had like 6 deps. It can happen, and it's a bit of a chore, but it can be done.

Re: AUR packages compromised with Infostealer and Rootkit

#157

Post by uecker »

no-name-here wrote: post #99
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…

> You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates. But isn’t that also the case for every browser extension, VSCode extension, nuget package, Cargo crate, python package, npm package, etc? (Unless you are running them somewhere without internet access or without access to anything you don’t mind being public?) Maybe it’s not the case for aur, but the…

Yes, use a distro with good security posture such as Debian to reduce risk.

Re: AUR packages compromised with Infostealer and Rootkit

#158

Post by backscratches »

2OEH8eoCRo0 wrote: post #92
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…

Why does nobody act like it is then? I don't use Arch but every Arch user talks about the Aur so matter-of-factly yet nobody treats it with the caution that it demands.

Every single app you've ever downloaded basically shares this same property. You either audited the code and know what it does or you are taking someone's word for it.

Re: AUR packages compromised with Infostealer and Rootkit

#159

Post by levkk »

UI_at_80x24 wrote: post #2

Here's an easy script to scan for compromised packages: https://cscs.pastes.sh/aurvulntest20260611.sh Not my script. It's easy to read/parse. Never pipe a script directly to bash.

This just checks if the package is installed, not if the installed version is infected. Presumably, if you (me...) haven't run `yay -Syu` in a while (months), we're fine, right? ...Right?

Goddamit, don't make me reinstall Arch, took me a week last time.

Update: archinstall rocks, back in business after like 15min.

Re: AUR packages compromised with Infostealer and Rootkit

#160

Post by OtomotO »

uecker wrote: post #157
no-name-here wrote: post #99

Earlier quoted context omitted.

> You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates. But isn’t that also the case for every browser extension, VSCode extension, nuget package, Cargo crate, python package, npm package, etc? (Unless you are running them somewhere without internet access or without access to anything you don’t mind being public?) Maybe it’s not the case for aur, but the…

Yes, use a distro with good security posture such as Debian to reduce risk.

Are the packages in the repositories of arch also affected?

No? Then it's not a problem.

Every device in this household that isn't a smartphone runs on Arch.

All my servers run on Arch.

Never had a problem, because I don't blindly install stuff from the AUR.

Post reply on HN