Live data from Hacker News

AUR packages compromised with Infostealer and Rootkit

discourse.ifin.network

111–120 of 234 posts

Re: AUR packages compromised with Infostealer and Rootkit

#111

This is one of the aspects of AUR which never fully convinced me: it purely hosts user-generated content, there's no review process or alike. I'd really prefer to see a model where a 'community' repository contains user submitted packages which have at least one Trusted User review the package before it's merged in. This doesn't just prevent malware, but also common mistakes in general.

How does a user become a Trusted User? Who is paying them to review everything?

Re: AUR packages compromised with Infostealer and Rootkit

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

I use Arch on my dev qemu VM and actually review all changes all the time.

It is not that hard with small amount of pkgbuilds:

  find ~/.cache/yay -maxdepth 1 -type d
  /home/virt/.cache/yay
  /home/virt/.cache/yay/google-chrome
  /home/virt/.cache/yay/ngrok
  /home/virt/.cache/yay/rancher-k3d-bin
  /home/virt/.cache/yay/simplescreenrecorder
  /home/virt/.cache/yay/ttf-comfortaa
  /home/virt/.cache/yay/cursor-bin
  /home/virt/.cache/yay/yay
  /home/virt/.cache/yay/volta-bin

Re: AUR packages compromised with Infostealer and Rootkit

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

They do? Arch exploded in popularity, but the forums were full of warnings.

My favorite Aur helper (pikaur) also asked you to check the PKGBUILD on every install or update, back when I used Arch.

Re: AUR packages compromised with Infostealer and Rootkit

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

My sense of it is that as linux is gradually inching towards the general power user audience, there's a lot of "just use [distro]" or fashionable distros where they're all seen as flavors of one thing. In a sense that's true, but not in others like this. I'd also add the various atomic distros like Silverblue or derivatives which have other conditions you need to learn to work with. For AUR it seems to get recommended as a secondary way to get software, if it hasn't been brought into the original distros package repos then the next step is to just search AUR, make the shortest line to the goal and don't worry about the details.

As far as Arch goes, I wonder if Arch-based CachyOS is a factor as it's seen the high performance desktop linux.

Re: AUR packages compromised with Infostealer and Rootkit

#115
post #108
post #95

Earlier quoted context omitted.

You seem confused about how the AUR works. There is no "client" like you're talking about that can show the user anything. There are AUR helpers, but these are completely unaffiliated with arch and the people running the AUR. The canonical, recommended way of installing arch packages is cloning a git repo, reading through the sources and then building it with makepkg. There is no client there that could show the user…

how comes gitlab shows custom messages to my plain old git client then? for example when you rename gitlab repository, or push to new branch, gitlab injects custom text that you can see. Eg. with new URL or where you can create merge request on web, etc...

I assume you're talking about the "remote: " messages? I've only ever seen those on push operations, not sure if they're even available for clone.

Maybe they'd be an option, but then the whole "making sure they've read the message before proceeding" part goes out the window.

Re: AUR packages compromised with Infostealer and Rootkit

#116
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…

> 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 what you're installing, they are very simple bash scripts. It'd be great if more people would donate resources to help verify and validate AUR scripts, but the AUR specifically exists for packages that the trusted users and devs of arch don't have time to personally maintain.

Re: AUR packages compromised with Infostealer and Rootkit

#117
post #96

This is one of the aspects of AUR which never fully convinced me: it purely hosts user-generated content, there's no review process or alike. I'd really prefer to see a model where a 'community' repository contains user submitted packages which have at least one Trusted User review the package before it's merged in. This doesn't just prevent malware, but also common mistakes in general.

This is essentially what the [extra] repository is. Not using the AUR and sticking to official Arch Linux packages exclusively is a very valid and reasonable choice (that I follow myself actually). A large number of "an Arch Linux update broke my system" is very likely due to incorrect AUR use that AUR helpers don't handle for you. There's an elaborate writeup here from just 2 months ago: https://lists.archlinux.org/…

Unless things have changed in recent times, packages in [extra] are maintained by TUs. Random users can't submit packages.

Re: AUR packages compromised with Infostealer and Rootkit

#118
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…

Some of these have corporate backing and/or better funding and thus more manpower to review things, but yeah it essentially applies to all of them. It's no accident that there's news about a new npm package being compromised every other week.

Ultimately, the way we're doing permissions on the OS level is fundamentally broken on desktop OSes, and we're increasingly feeling the effects of that. Ideally everything should be sandboxed by default, and only given access to it's own files, instead of everything the user has.

But we're a long way away from that, and that's not something a single project could enforce.

Re: AUR packages compromised with Infostealer and Rootkit

#119

The (Arch) community is moving quickly to release scripts/tools. Right now, this is the most up to date, consolidated utility to check for infection: https://github.com/lenucksi/aur-malware-check Also, the aur-request mailing lists has many delete/orhan requests coming through to undo the malicous commits: https://lists.archlinux.org/archives/list/aur-requests@lists...

Love the starchart at the bottom of the repo readme.

Really conveys that sense of urgency + the stakes tied to a major malware attack like that.

Re: AUR packages compromised with Infostealer and Rootkit

#120
post #55

7+ hours into this and still no mention on archlinux.org webpage nor on aur.archlinux.org. Why??? AUR should have been blocked until user takes action to prove he knows about this. Eg. change AUR API URL slightly so yay/yaourt users need to look up what is going on. New API should have infrastructure for informing users and making sure they've read the message before proceeding. Especially when they're not even sure…

IMO if numbers on Socket.dev can be trusted, then impact seems rather small (luckily). It also makes sense — I know some packages from the affected list, they're heavily outdated and their upstreams aren't maintained anymore.

Other than this — I don't know how many there are affected people in total, but AUR team probably has an exact number. I am also sure, they're doing their best to handle it accordingly to the impact.

Post reply on HN