Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AURpocalypse now: a look at the recent AUR attacks

lwn.net

Post reply on HN
Print view View original

81–90 of 104 posts

Re: AURpocalypse now: a look at the recent AUR attacks

#81

Post by embedding-shape »

diogenes_atx wrote: post #74
embedding-shape wrote: post #72

Earlier quoted context omitted.

In theory, you'd mostly care about exfiltration of data, so watching/actively managing exactly what network connections your computer/network can do, would give you upfront notification when it happens, but of course not earlier. And if your root/hardware somehow is infected, your monitoring/management tools might be affected too, so then you're basically out of luck except with external network gear outside of your…

> you'd mostly care about exfiltration of data, so watching/actively managing exactly what network connections your computer/network can do, would give you upfront notification when it happens If you have a list of good CLI utilities, you could run them in a bash script (e.g., network-monitor.sh), which would run in the background, and then redirect the output data to another file (e.g., network-monitor.txt). The key…

> tail your network-monitor.txt file to watch for anomalies in the network connections and check for any strange outflows of data

Don't do that, you can't rely on "watch for anomalies" with your human eyes.

Either you setup something that notifies you after the fact, or you outright block all incoming/outgoing connections until you approve them. Mentioned elsewhere I think in the thread, I think both OpenSnitch, Little Snitch and PiHole can help you with all of these things.

But don't assume you can "watch for anomalies", automation and/or gated access is probably the way to go.

Re: AURpocalypse now: a look at the recent AUR attacks

#82

Post by embedding-shape »

vlovich123 wrote: post #78
jchw wrote: post #40

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…

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

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

Re: AURpocalypse now: a look at the recent AUR attacks

#83

Post by diogenes_atx »

embedding-shape wrote: post #81
diogenes_atx wrote: post #74

Earlier quoted context omitted.

> you'd mostly care about exfiltration of data, so watching/actively managing exactly what network connections your computer/network can do, would give you upfront notification when it happens If you have a list of good CLI utilities, you could run them in a bash script (e.g., network-monitor.sh), which would run in the background, and then redirect the output data to another file (e.g., network-monitor.txt). The key…

> tail your network-monitor.txt file to watch for anomalies in the network connections and check for any strange outflows of data Don't do that, you can't rely on "watch for anomalies" with your human eyes. Either you setup something that notifies you after the fact, or you outright block all incoming/outgoing connections until you approve them. Mentioned elsewhere I think in the thread, I think both OpenSnitch, Litt…

> you can't rely on "watch for anomalies" with your human eyes

Yes, I agree, that's a good call. I would not try to check for anomalies manually with meatware. I would parse the data with python regex tools to establish a baseline and search for anomalous patterns.

I edited my post to reflect the change you suggested.

Re: AURpocalypse now: a look at the recent AUR attacks

#84

Post by ameliaquining »

embedding-shape wrote: post #82
vlovich123 wrote: post #78

Earlier quoted context omitted.

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

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

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.

Re: AURpocalypse now: a look at the recent AUR attacks

#85

Post by vlovich123 »

embedding-shape wrote: post #82
vlovich123 wrote: post #78

Earlier quoted context omitted.

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

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

> 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

Re: AURpocalypse now: a look at the recent AUR attacks

#86

Post by madduci »

jchw wrote: post #40

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…

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

Re: AURpocalypse now: a look at the recent AUR attacks

#87

Post by ameliaquining »

A lot of people in this thread seem to be treating this situation as a referendum on the security of package repositories that allow anyone to create a package. Possibly because that's interesting to more people, since npm and PyPI are more widely used than Arch.

But unless I've badly misunderstood something, the key thing that made this attack possible is this "orphaned" thing that lets you grant write access to an existing package to the first person who claims it, without any control over who that is. I don't see how this could ever be a safe thing to do, I'm not aware of any other package repository that has it, and I struggle to guess what whoever built it was thinking. If AUR just turned off that misfeature, they wouldn't be having this problem.

(The article quotes someone involved as saying that the "orphaned" feature is good because good actors can also use it, but that seems irrelevant if it also opens up an unmitigable machine-takeover vulnerability. World-writable single-namespace systems like Wikipedia work by having humans proactively checking for bad changes, and also by it not being that bad if a page is briefly defaced, since you can't push malware to users' machines that way.)

Re: AURpocalypse now: a look at the recent AUR attacks

#88

Post by embedding-shape »

vlovich123 wrote: post #85
embedding-shape wrote: post #82

Earlier quoted context omitted.

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

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

> orphaned packages don’t need to be adoptable - doesn’t have to be a flat global namespace

Those things sound worse for us who actually use the AUR the way it's meant to be used, being able to "orphan" packages for new maintainers to pick up bring us long-term stability. And since we review random 3rd party software we install from the internet, who does the actual edits doesn't really matter, as long as it's the right, simple little changes that updates usually are.

It's easy to complain about other volunteers to non-profit projects are not doing enough, but truth is that there is always a lot of stuff to do as an volunteer, and while you try to fight fire X, people scream about fire Y, and vice-versa, depending on which one made the news most recently. Sure they should be scanning things, sure the official repository should be super fast and always available, sure every package should always be problem free, but it's a human project driven by humans essentially for the love of the project itself, in one way or another.

Cargo in general have the benefit of being new (shoulders on giants and so on), and being made by people who knew what they were doing. NPM has had a long struggle with a lot of stuff though, and is today maintained by one of the largest companies in the world. I'm not sure they're really comparable here.

I do agree the process for which orphaned packages get new maintainers needs to change, obviously shouldn't be possible launch such automated attack. I don't agree with that the feature as a whole should go away, I do have my own packages that depend on other AUR packages, surely many of them have through the years changed maintainer, but shouldn't mean I need to suddenly start using a different package, as long as I continue reviewing the updates.

Re: AURpocalypse now: a look at the recent AUR attacks

#89

Post by gus_ »

embedding-shape wrote: post #81
diogenes_atx wrote: post #74

Earlier quoted context omitted.

> you'd mostly care about exfiltration of data, so watching/actively managing exactly what network connections your computer/network can do, would give you upfront notification when it happens If you have a list of good CLI utilities, you could run them in a bash script (e.g., network-monitor.sh), which would run in the background, and then redirect the output data to another file (e.g., network-monitor.txt). The key…

> tail your network-monitor.txt file to watch for anomalies in the network connections and check for any strange outflows of data Don't do that, you can't rely on "watch for anomalies" with your human eyes. Either you setup something that notifies you after the fact, or you outright block all incoming/outgoing connections until you approve them. Mentioned elsewhere I think in the thread, I think both OpenSnitch, Litt…

indeed OpenSnitch helps, pihole I'm not so sure (maybe if the c2c servers are in a blocklist...):

https://www.reddit.com/r/linux_gaming/comments/1u34pe3/comme...

Re: AURpocalypse now: a look at the recent AUR attacks

#90

Post by akerl_ »

einsteinx2 wrote: post #77
akerl_ wrote: post #73

Earlier quoted context omitted.

The AUR is, in my opinion, a pretty convenient selling point if you use any esoteric software. It’s basically like a crowdsourced set of people’s tips and tricks for installing stuff on Arch, all written in the format Arch uses for packages. Similar to how I’d not blindly take code from an AI and whack it into production, I wouldn’t blindly take an AUR PKGBUILD and execute it. But it’s nice to have a place to go see…

That’s a perspective on the AUR that I hadn’t really seen before from Arch advocates, in my (admittedly hazy memory) it’s usually mentioned in the sense of “Arch is great because you always get the latest packages in the official repos and basically anything you possibly need you can just install from the AUR”. If you’re actually using it just as a reference guide essentially then it seems like there’s some value the…

There are also dangers of being on older versions in Debian that rely on maintainers identifying and correctly back porting critical changes.

Fwiw the Arch docs are pretty clear that the AUR is a Wild West and that you should be vetting anything you find there before you run it.

Post reply on HN