there have been multiple package list checkers released, but unclear which ones are trustworthy, I can't immediately find a list from the official channels (through AUR website) to such approved scanners?
AURpocalypse now: a look at the recent AUR attacks
91–100 of 104 posts
Re: AURpocalypse now: a look at the recent AUR attacks
#92Earlier quoted context omitted.
> 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...
I though Pihole could act as a "whitelist-only" DNS server but maybe I'm wrong, that could be an additional layer.
Re: AURpocalypse now: a look at the recent AUR attacks
#93Humble question: how do you find out if your system has been affected by a malware? I know that for AUR there was a specific list of affected packages (that I checked, and haven't installed any of them), but I'm interested more in a general way. It could be from AUR, npm, or many other sources. Some malware could break and lock immediately the system, but other could stay there silent for months, so how to find out i…
> Some malware could break and lock immediately the system, but other could stay there silent for months, so how to find out if there is any?
>
> I haven't run an antivirus since I last used Windows 20 years ago.
That'd be the role of an IDS (Intrusion Detection System). Things like file signatures of your entire system being saved to another machine (for example an offline/airgapped one) beforehand (for example by plugging your main machine's SSD as a secondary drive on the airgapped one).
If you suspect shenanigans, you take your machine offline, you remove its SSD (your BIOS/UEFI is also a concern), plug it to your airgapped machine with the IDS: it compares all the files (binaries, config files, etc.)' checksums with the past ones.
It's a bit of a lost art but it could make a comeback seen what we're facing, now nearly on a weekly basis.
Some distros have a way to check for file integrity as part of the package manager: but you can't trust the infos coming from the machine itself if it's been compromised.
Re: AURpocalypse now: a look at the recent AUR attacks
#94There are automated scripts to check if the infected AUR packages are installed on your system:
https://forum.endeavouros.com/t/malicious-aur-checkup-script...
Re: AURpocalypse now: a look at the recent AUR attacks
#95Earlier quoted context omitted.
> 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.
Also bear in mind, that many rootkits hide processes and connections from command line tools like ps, top, lsof, netstat, ss, etc...
In this particular malware campaign, the malware contained a rootkit which hid precisely some of its activity:
https://github.com/gustavo-iniguez-goya/decloaker/discussion...
Re: AURpocalypse now: a look at the recent AUR attacks
#96Earlier quoted context omitted.
> 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 ri…
> 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.
This is the problem - the AUR has outgrown this mindset and this resistance to recognize this fact is precisely why this problem will keep coming up. You’re essentially there in some ways without admitting it because of new account creation is disabled. The next attack vector will be taking over existing accounts that aren’t used.
Think of it this way - Arch is a niche distro within a niche desktop OS and still it was cheap enough of an attack that it was worth it. It’s a cultural problem and your mindset is precisely why this will keep happening. As an Arch user I’m honestly embarrassed and I’m going to be looking at distros that aren’t user hostile like this.
Re: AURpocalypse now: a look at the recent AUR attacks
#97The 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.
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.
Re: AURpocalypse now: a look at the recent AUR attacks
#98Earlier 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 issue with the AUR is that its design and the way package maintainership works puts users at undue risk compared to many other "user" repositories. This happens because so many useful packages are only available in the AUR to begin with, but also because the mechanism for taking over an orphaned package is just simply too open for exploitation.
I don't have all the answers. I hope people will consider Nixpkgs as a powerful model: even though it has many thousands of PRs unmerged at any given time and requires substantial effort, it still operates at an absurd scale and yet has a higher bar to infiltration with malware, both due to build sandboxing and due to the review process. Whereas AUR maintainership is mostly handled individually per-package, anyone can submit changes to a Nixpkgs and try to get it reviewed, even if the maintainer of an individual package is long gone (though we usually give maintainers a week or so to take a look at a PR even once it has been reviewed.) This entirely gets rid of both the need and incentive to have a process to replace an orphaned package's maintainer: writing yourself in as the maintainer mostly just signs you up to get pinged for issues and PRs, it doesn't grant you special permissions to bypass the normal review process.
A giant monorepo of PKGBUILDs with a similar maintainership model plus makepkg sandboxing would be fantastic. makepkg sandboxing would be nice just for ensuring that packages correctly declare their dependencies.
I think the sandboxing thing has a better shot at actually happening, since redesigning the entire AUR around a completely different model is probably an unreasonable leap. That'd still be a pretty good improvement, though.
Re: AURpocalypse now: a look at the recent AUR attacks
#99Re: AURpocalypse now: a look at the recent AUR attacks
#100Earlier quoted context omitted.
Is there another distro that has an equivalent of the AUR with handling you think is preferable?
Windows where you just download .exe and .msi files from random websites. Not a Linux distro, but the closest security model I can think of.
You think that users having to find and download software from the Internet at large is both similar to the AUR model and has preferable handling of these issues?
Can you elaborate?