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

211–220 of 234 posts

Re: AUR packages compromised with Infostealer and Rootkit

#211

Post by nagaiaida »

Matl wrote: post #139
DavideNL wrote: post #130

Earlier quoted context omitted.

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

> like github repos that don't seem relevant

i wouldn't necessarily trust a repo that does seem relevant either. it's trivial to put any data you want at a url which, at a glance, appears to legitimately belong to any repo you can fork.

Re: AUR packages compromised with Infostealer and Rootkit

#212

Post by drankinatty »

VladVladikoff wrote: post #93
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 Believing that even a small fraction of users actually do this is deeply detached from reality.

"Review every PKGBUILD" is as realistic as expecting the EULA to be completely read and understood (including the forced arbitration clause) before clicking "I Agree". It also ignores the poor souls using AUR helpers that automatically download and build packages from AUR as they were designed to do for the convenience of Arch/AUR users.

AUR isn't just some download site. It has been actively marketed by Arch for at least the 17 years I've used Arch as it's user repository. (that's kinda the acronym)

That creates the expectation, rightly or not, that the Arch User Repository provides some degree of protections for Arch Users against the build sources hosted there being compromised.

The AUR is a great resource for Arch and the wider Arch community and it was put together by some really talented folks at a time when the threat environment was completely different. Times have changed, and it's a sad testament for humanity.

AUR will get through this, and be better for the additional guardrails to be put in place, but blaming the victim and CYA never gets you there.

Re: AUR packages compromised with Infostealer and Rootkit

#213

Post by j-bos »

Ferret7446 wrote: post #202
j-bos wrote: post #144

Earlier quoted context omitted.

Yeah, I don't even use the AUR. If I need something, I'll just build it myself. Convenience is dangerous.

> If I need something, I'll just build it myself That's basically what the AUR is.

Except for the "you"rself part.

Re: AUR packages compromised with Infostealer and Rootkit

#214

Post by rossvor »

Hackbraten wrote: post #207
rossvor wrote: post #94

Earlier quoted context omitted.

I don't have it installed, so I can't comment if it requires constant babysitting, but looks pretty okay to me -- it has no AUR-only dependencies (++), one extra shell script (--), popular (++ given enough eyeballs...). Should be fairly easy to review, anything fishy should be fairly visible in git diff. If I needed it I would be using this PKGBUILD. It's a net gain that it exists there, someone else done most of the…

> There is no trusted user™ who uses spotify, so it's not in official packages That's not the reason why Spotify is not on extra. Spotify is not on extra because it's not FOSS.

That is not true, there are plenty of non-FOSS packages in extra/multilib (e.g steam, discord, nvidia). The only criteria is if there is an interested packager to maintain it.

>The large number of packages and build scripts in the various Arch Linux repositories offer free and open source software for those who prefer it, as well as proprietary software packages for those who embrace functionality over ideology.

[1] https://wiki.archlinux.org/title/Arch_Linux

[2] https://wiki.archlinux.org/title/Nonfree_applications_packag...

[3] https://bbs.archlinux.org/viewtopic.php?id=272134

[4] https://bbs.archlinux.org/viewtopic.php?id=273609

Re: AUR packages compromised with Infostealer and Rootkit

#216

Post by cncjvu7 »

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…

> All of that being said, the era of allowing anyone to adopt AUR packages might be coming to an end.

Should have never been a thing.

I hope we end up with something more like username/packagename-bin|git

That'll make it way more obvious to people what they're really installing and from who.

Re: AUR packages compromised with Infostealer and Rootkit

#217

Post by cncjvu7 »

codemac wrote: post #173
craftkiller wrote: post #164

Earlier quoted context omitted.

> The advantage to the AUR is just that you can reasonably review every PKGBUILD for what you're installing Simply reviewing the PKGBUILD is not enough for the same reason reviewing a Makefile is not enough: You need to review the source code for _everything_ that is being downloaded and executed on your machine. For AUR packages, that means not just the PKGBUILD but the full source code for the program it is buildin…

Right, the PKGBUILD only helps you review if you're installing what you intend to - not verifying if what you're installing contains any hacks. This hack in particular added random npm packages that would have been unneeded/unintentional, and was visible in the PKGBUILDs directly.

No it wasn't? It ran npm install from post install script in another file. If they named it better people probably wouldn't have even noticed so quickly.

Re: AUR packages compromised with Infostealer and Rootkit

#218

Post by dathinab »

ateles wrote: post #192
dathinab wrote: post #42

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

> Luckily for most packages this is reasonably doable, IFF you trust the upstream sources they fetch from. Don't forgot to also check the applied patch files. Many AUR builds include custom patches to make something work, making this a convenient way add something malicious into the build. An extreme example for patches is ventoy's 1355 line long PKGFILE [0] sourcing lots of patches both from external domains as well…

For completeness another trick to deceive people can be to have (git/http) sources from places other then just the official repo, like in the example you linked. When changed they will just show up as a a "hash" change... which is fine for the original upstream source (if trusted) but not for anything else.

But in general I would think 4 times about installing any AUR package no longer reasonable reviewable in the parts not either in official packages or the upstream source (including patches, dependencies, etc.).

Sometimes throwing something into an untrusted OCI image you run in a VM (instead of lightweight containers) is just the better option... sadly, also often still painful to setup.

Post reply on HN