3 ms·

The AUR really has been known to be low-hanging fruit for bad actors, which makes it somewhat surprising it took this long for it to be taken advantage of. I h

by jchw 4mo ago

The AUR really has been known to be low-hanging fruit for bad actors, which makes it somewhat surprising it took this long for it to be taken advantage of. I have many opinions regarding this situation, but it mostly doesn't matter. AUR staff and AUR helper developers will figure out what they want to do, hopefully they will find a good approach. But what I personally take away from this is simply that it has become worth it to target desktop Linux with malware. Or at least, moreso than previously. It is perhaps a good sign in some ways that the desktop is starting to be taken more seriously. The bad news, of course, is that the Linux desktop is a bit of a train wreck in terms of security hygeine. It's getting better, and Linux does have the advantage of having some powerful primitives to exploit, but the desktop suites come from a totally different world, and I fully expect we'll also see more malware propagated through KDE's New Stuff integration (which goes through Pling.)

Normal_gaussian 4mo ago
I'm not sure if it is that the desktop is being taken more seriously, or that its easier to write code that works on many distributions and configurations, greatly reducing the cost and increasing the value of the existing 'market'.
npodbielski 4mo ago
I would say that it is now very easy to steal 'AI' providers credentials this way. And then you can use them to write more malware or scam or use models for generating speech to call people and get them to 'redeem'. Or at leat to me this seems more sensible than injecting just malware.
exceptione 4mo ago
> It's getting better, and Linux does have the advantage of having some powerful primitives to exploit, but the desktop suites come from a totally different world, When opening the printer configuration page in the KDE configuration panel, I was pleasantly surprised to see it's process runs wrapped inside a bwrap session. Cups is a bit of old and dangerous; I'm glad they sealed that off inside a sandbox. If you ask me, I would make this approach the standard for any software. The configuration panel for fonts doesn't need network access, so at least `bwrap --unshare-net`
graemep 4mo ago
I think KDE's approach is a greater danger. They both come with warnings, but with AUR (depending on tools) allows you to inspect the PKGBUILD. KDE just gives you a warning and no easy way of looking at what you are installing, it is not clear what contains executable code, and its enabled by default. In general things that are not part of your distro's supported repos (KDE's AUR, language package installers like npm and pypi, Ubuntu PPAs, etc.) seem to present far more of a risk.
vlovich123 4mo ago
> But what I personally take away from this is simply that it has become worth it to target desktop Linux with malware. Or at least, moreso than previously. It is perhaps a good sign in some ways that the desktop is starting to be taken more seriously. Absolutely the wrong conclusion: 1. This is a super low hanging fruit attack 2. The ROI is significantly higher than the cost of attack 3. The cost of the attack is now drastically reduced due to LLMs (not that they necessarily mattered here but hard to rule out). It’s less about the Linux desktop where Ubuntu is dominant and more that Arch security is so bad regarding how they maintain the AUR. Seriously it’s worse than Swiss cheese in terms of putting up roadblocks.
- embedding-shape 4mo ago
  > that Arch security is so bad regarding how they maintain the AUR I still don't understand what people expect Arch to do here? It's a user-contributed repository open for anyone, Arch maintains their own official repositories that are separate from AUR, what would need to change in the maintenance of the AUR for you to consider it to be "properly run" or whatever, and it doesn't stop serving its core purpose anymore: to allow any user to upload any PKGBUILD? If you're advocating for not allowing users to upload their own PKGBUILD anymore, then it stops being the AUR, and for the people who agree with that, they can already exclusively use the official repositories instead of touching the AUR. In true Arch fashion, the security is up to you here, review stuff before installing 100% unknown and random 3rd party software from the internet, as always. If you don't want to review anything? Stick with official stuff, and you won't have issues.
  - ameliaquining 4mo ago
    It seems obvious to me that they should get rid of this "orphaned" designation that allows anyone to grab a package and start pushing updates, because there's no circumstance under which that's a good idea.
  - vlovich123 4mo ago
    > The AUR is maintained by Arch's Package Maintainers So, firstly it is their responsibility. The consequences are a direct result of their policies. Example of changes: * orphaned packages don’t need to be adoptable. * doesn’t have to be a flat global namespace * they could have offered the cooldown capability a long time. This isn’t an area they focus on until they’re absolutely forced into it through sheer embarrassment of the scale of the attack. * they could be running scanning tools on every change to try to catch low effort attacks like this But sure, if you throw up your hands and say “we’ve tried nothing and nothing works” then you shirk all responsibility. And maybe shutting down the AUR is the right move if the current incarnation is so bad and the people running it don’t know how to secure it. Think of it this way - the NPM and cargo registries handle way more traffic and visibility and doesn’t have any issues like this. There they have to deal with more complicated supply chain attacks. Ubuntu and Fedora take a completely different tack with user-contributed packages that are namespaced and better sealed. And part of this of course is that yay and ilk don’t do proper sandboxing. But that’s just more shirking of responsibility by the AUR maintainers to force the community to try to do this and failing to treat this as an end to end problem they need to own
madduci 4mo ago
I don't know how long will it take to attack also flatpak/flathub and snap stores as well.
- jchw 4mo ago
  Snap has had a couple of attacks, at least. I recall one that was a fake crypto wallet. I'm sure Flathub has, too. That said: the attacks on Snap and Flatpak are bound to be less interesting; it doesn't share the same mechanics that make AUR scary. I still hope that Linux infrastructure vendors work to come up with good ways to "raise the floor" in these cases.

by jchw 4mo ago

Normal_gaussian 4mo ago

I'm not sure if it is that the desktop is being taken more seriously, or that its easier to write code that works on many distributions and configurations, greatly reducing the cost and increasing the value of the existing 'market'.

npodbielski 4mo ago

I would say that it is now very easy to steal 'AI' providers credentials this way. And then you can use them to write more malware or scam or use models for generating speech to call people and get them to 'redeem'. Or at leat to me this seems more sensible than injecting just malware.

exceptione 4mo ago

> It's getting better, and Linux does have the advantage of having some powerful primitives to exploit, but the desktop suites come from a totally different world, When opening the printer configuration page in the KDE configuration panel, I was pleasantly surprised to see it's process runs wrapped inside a bwrap session. Cups is a bit of old and dangerous; I'm glad they sealed that off inside a sandbox. If you ask me, I would make this approach the standard for any software. The configuration panel for fonts doesn't need network access, so at least `bwrap --unshare-net`

graemep 4mo ago

I think KDE's approach is a greater danger. They both come with warnings, but with AUR (depending on tools) allows you to inspect the PKGBUILD. KDE just gives you a warning and no easy way of looking at what you are installing, it is not clear what contains executable code, and its enabled by default. In general things that are not part of your distro's supported repos (KDE's AUR, language package installers like npm and pypi, Ubuntu PPAs, etc.) seem to present far more of a risk.

vlovich123 4mo ago

> But what I personally take away from this is simply that it has become worth it to target desktop Linux with malware. Or at least, moreso than previously. It is perhaps a good sign in some ways that the desktop is starting to be taken more seriously. Absolutely the wrong conclusion: 1. This is a super low hanging fruit attack 2. The ROI is significantly higher than the cost of attack 3. The cost of the attack is now drastically reduced due to LLMs (not that they necessarily mattered here but hard to rule out). It’s less about the Linux desktop where Ubuntu is dominant and more that Arch security is so bad regarding how they maintain the AUR. Seriously it’s worse than Swiss cheese in terms of putting up roadblocks.

embedding-shape 4mo ago
> that Arch security is so bad regarding how they maintain the AUR I still don't understand what people expect Arch to do here? It's a user-contributed repository open for anyone, Arch maintains their own official repositories that are separate from AUR, what would need to change in the maintenance of the AUR for you to consider it to be "properly run" or whatever, and it doesn't stop serving its core purpose anymore: to allow any user to upload any PKGBUILD? If you're advocating for not allowing users to upload their own PKGBUILD anymore, then it stops being the AUR, and for the people who agree with that, they can already exclusively use the official repositories instead of touching the AUR. In true Arch fashion, the security is up to you here, review stuff before installing 100% unknown and random 3rd party software from the internet, as always. If you don't want to review anything? Stick with official stuff, and you won't have issues.
- ameliaquining 4mo ago
  It seems obvious to me that they should get rid of this "orphaned" designation that allows anyone to grab a package and start pushing updates, because there's no circumstance under which that's a good idea.
- vlovich123 4mo ago
  > The AUR is maintained by Arch's Package Maintainers So, firstly it is their responsibility. The consequences are a direct result of their policies. Example of changes: * orphaned packages don’t need to be adoptable. * doesn’t have to be a flat global namespace * they could have offered the cooldown capability a long time. This isn’t an area they focus on until they’re absolutely forced into it through sheer embarrassment of the scale of the attack. * they could be running scanning tools on every change to try to catch low effort attacks like this But sure, if you throw up your hands and say “we’ve tried nothing and nothing works” then you shirk all responsibility. And maybe shutting down the AUR is the right move if the current incarnation is so bad and the people running it don’t know how to secure it. Think of it this way - the NPM and cargo registries handle way more traffic and visibility and doesn’t have any issues like this. There they have to deal with more complicated supply chain attacks. Ubuntu and Fedora take a completely different tack with user-contributed packages that are namespaced and better sealed. And part of this of course is that yay and ilk don’t do proper sandboxing. But that’s just more shirking of responsibility by the AUR maintainers to force the community to try to do this and failing to treat this as an end to end problem they need to own

madduci 4mo ago

I don't know how long will it take to attack also flatpak/flathub and snap stores as well.

jchw 4mo ago
Snap has had a couple of attacks, at least. I recall one that was a fake crypto wallet. I'm sure Flathub has, too. That said: the attacks on Snap and Flatpak are bound to be less interesting; it doesn't share the same mechanics that make AUR scary. I still hope that Linux infrastructure vendors work to come up with good ways to "raise the floor" in these cases.