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

81–90 of 234 posts

Re: AUR packages compromised with Infostealer and Rootkit

#81

Post by bachmeier »

rossvor wrote: post #72
bachmeier wrote: post #59

Earlier quoted context omitted.

Honestly, it's hard to see how Arch is a usable distro for most potential users without AUR. If you want a large selection of official packages, the Debian world is going to be the better choice.

Obviously usages vary greatly, but I doubt it's that of big deal for majority of Arch users (maybe it's different for Arch derived distros). My AUR maintained package count has been in single digits for decades (both on my home PC and work station), and I don't think it as a heavy burden to update those packages. There's a certain selection bias going on here -- I drop AUR packages if they become too annoying (if the…

I think the issue with AUR is that you get your foot in the door with packages like spotify[1]. It does its magic to allow you to install a .deb package on your distro. I don't know how else to install the Spotify desktop app without AUR. But once you're willing to do that, why not go a little further and trust other packages?

Now, someone could argue that the Spotify app isn't important, but there's a reason it has 268 votes. A better solution would be having packages like spotify in their own repo, and a separate, you-better-verify repo for the rest.

[1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=spoti...

Re: AUR packages compromised with Infostealer and Rootkit

#82

Post by Vexs »

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 entire dep chain by hand. Mind you, I don't have a solution either.

Re: AUR packages compromised with Infostealer and Rootkit

#83

Post by harvie »

Tharre wrote: post #71
harvie wrote: 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…

No it shouldn't. You don't break everyone's workflow just because some people refuse to take basic security advise seriously. > New API should have infrastructure for informing users and making sure they've read the message before proceeding. How would that even work? AUR packages are just git repos, everything that AUR helpers are doing or not doing is not under the control of the arch maintainers.

> How would that even work?

Are you seriously asking how would sharing short text notes over internet work?

If you need to be 100% git-centric, you can have git repo for messages. Client will then remember last commit displayed to user and refuse to continue unless latest message was displayed.

BTW some AUR clients displayed ArchLinux RSS feed before... Too sad the issue is not even mentioned in the RSS feed...

Re: AUR packages compromised with Infostealer and Rootkit

#84

Post by DavideNL »

keysersoze33 wrote: post #74

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

Noob question, but how do people know this is thrustworthy, since it's not from Arch / an official source?

There's a lot of voodoo in that script, i can't easily tell it's safe by reading the code.

I'd expect some reaction/solution from official Arch developers...

Re: AUR packages compromised with Infostealer and Rootkit

#86

Post by hootz »

rossvor wrote: post #79
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...

You are thinking of the alarm fatigue[1], but it doesn't apply here -- there are no constant alerts warning that you are doing something dangerous to the point you get desensitized and start to ignore them. The correct analogy here are checklists -- things that you need to check if you are to do this "dangerous" activity (AUR usage), akin to pre-flight checklist. [1] https://en.wikipedia.org/wiki/Alarm_fatigue

Oh yeah, that's the name of it. But I guess something similar happens with checklists, you do it so many times without anything bad ever appearing that you start to subconsciously assume nothing will ever happen. Why check the rotor of my helicopter when nothing ever happened to it for 5 years? This checklist is a waste of time!

Re: AUR packages compromised with Infostealer and Rootkit

#87

Post by kpcyrd »

harvie wrote: post #83
Tharre wrote: post #71

Earlier quoted context omitted.

No it shouldn't. You don't break everyone's workflow just because some people refuse to take basic security advise seriously. > New API should have infrastructure for informing users and making sure they've read the message before proceeding. How would that even work? AUR packages are just git repos, everything that AUR helpers are doing or not doing is not under the control of the arch maintainers.

> How would that even work? Are you seriously asking how would sharing short text notes over internet work? If you need to be 100% git-centric, you can have git repo for messages. Client will then remember last commit displayed to user and refuse to continue unless latest message was displayed. BTW some AUR clients displayed ArchLinux RSS feed before... Too sad the issue is not even mentioned in the RSS feed...

There's no shortage in ideas of how to make the AUR easier to moderate. A "quarantine button", an invite system, a request system for adoption similiar to how orphan requests work, code review attestations similiar to cargo-crev, pacing controls similiar to those in discourse.

There is a shortage however of people skilled enough to implement them (with available time to do so).

What we also don't have a shortage of is angry people in comment sections.

Re: AUR packages compromised with Infostealer and Rootkit

#88

Post by opan »

hootz wrote: post #86
rossvor wrote: post #79

Earlier quoted context omitted.

You are thinking of the alarm fatigue[1], but it doesn't apply here -- there are no constant alerts warning that you are doing something dangerous to the point you get desensitized and start to ignore them. The correct analogy here are checklists -- things that you need to check if you are to do this "dangerous" activity (AUR usage), akin to pre-flight checklist. [1] https://en.wikipedia.org/wiki/Alarm_fatigue

Oh yeah, that's the name of it. But I guess something similar happens with checklists, you do it so many times without anything bad ever appearing that you start to subconsciously assume nothing will ever happen. Why check the rotor of my helicopter when nothing ever happened to it for 5 years? This checklist is a waste of time!

That one's survivorship bias I think.

Re: AUR packages compromised with Infostealer and Rootkit

#89

Post by kpcyrd »

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…

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.

Re: AUR packages compromised with Infostealer and Rootkit

#90

Post by opan »

datakan wrote: post #26
sva_ wrote: post #3

Earlier quoted context omitted.

It isn't guaranteed that the list is conclusive. Always check PKGBUILD and sources, AUR is not to be trusted for the most part. I'm actually more surprised that such compromise hasn't happened earlier.

> I'm actually more surprised that such compromise hasn't happened earlier. This is like the 3rd or 4th time. It's been ongoing and persistent for the last 2 years with frequent AUR downtime as a result. The AUR should be deprecated in its current state, simply can't be trusted and is a blemish on an otherwise great distro.

I have long thought that fewer things get properly packaged for Arch due to it having the AUR as a crutch. Stuff like Void and Guix will have packages that are only in the AUR for Arch.
Post reply on HN