Hundreds of AUR packages attacked by infostealer
143 points by vivicat
143 points by vivicat
More info in Mastodon post: https://gaysex.cloud/notes/andaxow7itfn05x9
List of affected packages: https://gr.ht/aur_pkg_list.txt
Important security details published on the domain gaysex.cloud is the most Fediverse thing ever. ♥
I had to think twice about posting it to our internal Slack but please do continue with this and make it that all security updates are to be shared from NSFW domains.
I've definitely passed along interesting infosec updates to my team that originated from the yiff.life instance.
Yeah, because it was a new domain, lobsters wouldn't even let me post that as the main link, haha.
It was a new domain and you're a new poster. (Welcome!) Once you've been around a bit, you'll be able to post new domains.
Also, I clicked through to your homepage and your explanation of your pronouns is my favorite one ever. Nice work!
This will probably end whatever trust the community has in anonymous and unverified contributions from the community. It's like seeing trust erode away in real time.
...to be honest? Good, this is overdue. Our industry needs to wake the fuck up.
We trust computers with so much private, sensitive data. They are the center of our modern lives. If your personal computer gets infected, that's a downright catastrophic event - at best you can just hope that you're boring enough that the hacker doesn't decide to fuck with you in particular.
Yet, for some reason, we've normalized running every random fucking thing with full privileges[1], and then we act surprised whenever that turns out to be a bad idea.
[1] of your current user. root is basically meaningless on most setups
UPDATE: On reflection, I think wake-up calls can be blessings in disguise. It's a matter of degrees. I left my original comment below.
...to be honest? Good, this is overdue. Our industry needs to wake the fuck up.
It's not good for the community to have to divert their limited resources to address threats that have grown.
Its just bad, even if lots warned of the threat, since of the many things a distribution has to care about, security is just one.
There are, after all, open OS choices that have a stronger story here (QubesOS, AOSP), but they have their own limitations.
Further, I worry the result isn't that all open OSs manage to develop workflows/isolation that allow only accepting PoLP community contributions.
I worry that the result is that highly-sensitive services push more for locked down OSs.
Android and iOS have shown that there is more an OS can do in terms of isolating apps. Desktop has just not caught up sufficiently fast and Linux is especially bad.
Edit: And to me this is not just
I don't know there are a lot of things wrong with computers. Many due to legacy, many probably due to performance. In terms of real security it seems we are at
iOS/Android > MacOS > Windows > Linux
I agree generally that desktop OSs have a long way to go in terms of security, I just want to quibble with the order you've got at the end there.
Linux is not a monolith, and different distros have very different security affordances. Like, there's QubesOS, which I would rank as more secure than macOS.
There's also ChromeOS/ChromiumOS on Chromebooks, another linux distro, which I would also rank as more secure than macOS.
Distros like Arch where it's very common to enable third-party community repositories I would rank as less secure, while distros where it's uncommon to enable third-party repositories and maintainers do a good job of reviewing package updates are more secure (in comparison to other Linux distros).
Fair, I was speaking of let's say "traditional" Linux distributions. I would say the Ubuntus, Fedoras, Arches, Gentoos, Mints, etc.
For QubesOS, I have actually tried to use that as a daily driver for a few months and it was so exhausting that I do not want to compare it. Maybe it's more secure. So is not using a computer. :D
Yeah, security can not be viewed entirely separately from usability. Perfect isolation is not hard to achieve, we've known about air gaps forever. What's hard is making resource sharing work while maintaining security.
I'm thinking that an immutable Linux system with atomic updates, and user applications only installed as Flatpaks propably does about as well as MacOS on app isolation. Flathub has its own set of issues, though.
Maybe, I haven't dug into the security of Flatpaks recently. I do find this questionable in the sense that it is not a default setup anywhere, afaik.
There's also the sort of median ground of flatpaks, which have capabilities but often they're set very wide, and they're up to the package maintainer to set so only really a defense against a rogue library or privilege escalation attack.
To be fair -- and this is the ugly side of the desktops haven't caught up part -- it's not always the package maintainers' fault. Lots of these applications were written before sandboxing was a thing, so some of them just outright crash without very open permissions. Then, when permissions are enforced, without Android's extensive use of mount namespacing, they're kind of awkward to use or limited in what kind of sandboxing they enforce.
just outright crash without very open permissions
My experience running a lot of heavy-ish stuff in nsjail is: give an application an illusion of a normal but minimalistic and empty system, and it will work.
Sure, there are limitations to isolation, but those are about things where the access is granted.
The idea that sandboxing is about denying access to APIs instead of things behind the APIs is convenient for gatekeepers, but does not really add to security.
Yeah, that's my experience as well, and why I like mount namespacing so much (or, who knows, I spent too much time in Plan 9 land forever ago and now I'm just too refractory in this regard). Just give applications a home folder to play with if that's what they want, as long as it's not my real home folder.
Horrifyingly, this is somewhat of a precaution in general, but it is also a usability question for me by now.
Only the needed files, and the directories in question count as mounts definitely improves UX in file-selection dialogs. And no application can flip some setting persistently without telling me! And I can give a specific username to an application that wants username for something without a trivial way to change it! Applications get to believe that local TCP port 631 is what I want you to use as CUPS, even if it is remote! etc.
Yes! One pipedream that I have is the ability to define workspaces in terms of namespaces. E.g. if I'm working on my toy kernel, I'd love for my view into ~/workspace to be just a handful of repositories I work with (both my own and the ones I occasionally study, like the NetBSD source tree).
Well, in my pipe dream project, this is pervasive across applications: e.g. my view into the Zotero library to be a handful of sub-collections (technical references, OS papers and so on), to map only part of my bookmarks collection into the web browser, and so on. Basically, I can tag information with the views it's part of, and I can always "dig down" to one of the views.
This is obviously not feasible anywhere in the current computing stack, it's one of those grand visions of things for when I play armchair architect. But in general I think sandboxing by actually handing off a sandbox on the application side, and being able to stitch/share sandboxes on the system side, is a very powerful primitive, which takes a lot of the pain of sandboxing-by-denial away from legacy applications.
I have mixed feelings about whether this is universally applicable and/or a good idea in general, but with practically all of the desktop being a giant legacy application at this point in the computer industry's timeline, it's... maybe not the worst.
This is obviously not feasible anywhere in the current computing stack
Erm, I am like a third way there, and not halfway only because some of your wishes don't perfectly align with mine when I am on my own (but I could be interested in working together to fill the gaps)?
Like,
For Zotero, a single SQLite database is of course an issue. I guess you could write some extractor scripts to create a sub-view, then run a sync server locally for merging? Might work, but will be annoying.
Actually, if you (or anyone else active on Lobste.rs, or anyone having something interesting that is visible elsewhere as proof-of-being-interested-in-things) want to discuss in details what is cheap-ish to achieve, or what costs I can already paid and can help reproduce the setup, maybe there is a limit on how much details make sense literally in this thread, but I would be interested to chat!
Oh, nice! That actually sounds encouraging!
I tried something like that forever ago, although with a far more horrifying stack -- basically I'd read a piece from Jessie Frazelle about how she used Docker and I figured, okay, now Docker makes a bit of sense, how about I try it. That's actually how I learned to use Docker and what made it click for me. But I never took it too far. Since I'm not actually a sysadmin or a DevOps guy what regularly happens with any non-trivial Docker setup is that I build it once, I get it working after enough yelling and cigarettes, it works fine for a year or so, and then when I need to add something to it I can't for the life of me even remember how and why it works.
For Zotero, a single SQLite database is of course an issue. I guess you could write some extractor scripts to create a sub-view, then run a sync server locally for merging? Might work, but will be annoying.
I'm reluctantly using Zotero mostly because it's the only thing that's (still) local enough but its storage backend isn't great. It's a giant SQLite blob that I'm kind of afraid to touch. But I suspect what would actually work reasonably well (with the caveat that "child" views would be read-only) would be just copying and pruning the database, while mounting the storage directory separately. That would still mean all the files in the library are accessible, but it's not like you're accessing them through the file browser most of the time, so it's not that bad.
I mean, my stack is also cursed, I have a daemon in Common Lisp running as root where I didn't bother to fix a file descriptor link so it just restarts from time to time.
nsjail is somewhat straightforward, which makes driving it easy. And I am fine sharing the entire Nix store into the jails, so no image management at least.
Zotero
In principle, you could consider an inverse approach: store files and PDF conversions and .bib snippets, annotate PDFs in Xournal++, do content search with Recoll or something (or just store text exports and use grep-family stuff)?
I guess another option is forking the sync server for bidirectional filtered sync.
MacOS really doesn't deserve a position that high. Their security layer is extremely coarse - "do you want full access to all documents - yes/no". At the same time they deprecate the one sandbox mechanism that everyone uses in practice. They had tags, file metadata, full indexing and ownership of the high level file access layer - and decided to basically not do anything with that beyond "this is downloaded from the internet so you need 3 more clicks".
At the same time Xcode tools can just silently exfilrate any files from your disk - "not a security issue* apparently.
why do we not have a way to use a library without sharing an address space
We had a chance to both make this more extreme and more secure we the same time https://en.wikipedia.org/wiki/Singularity_%28operating_system%29
Thank God. Imagine if we had to go through some third party app signature process to install the home made pipì_koko exporter daemon set to a k8s cluster.
We have seen this with the SSL market: it’s a security theatre at best.
Yes, it's annoying if you're a developer, and certainly there are ecosystem concerns with e.g. Google requiring everyone who wants to write an Android app to have an account with them. However, in total most users are not developers and overall security improves.
I would say the SSL market is a different case. Certainly, charging people money for creating certificates was bad. Certainly, the fact that you could get spoofed EV certificates. But you can register "google.cam" and get a certificate for it and scam people. Certificates tried to solve the problem of "help people make sure they are connecting to the right something" and some of that failed. But the idea was not weird and requiring proof of government ID for certificates makes sense in that light. I don't think we can say all attempts at verification are bad because of this.
why do we not have a way to use a library without sharing an address space
On which CPU won't it have significant overhead comparable to process switch? (Running some operations in a separate, somewhat constrained, processes is practiced sometimes, but this is an application developer choice, maybe unfortunately)
why can a function even change things that were neither passed in nor returned
Because CPU economies of scale are such that CPUs with better memory models are impractical (although I guess Apple do their own CPUs anyway so they could?)
why does a desktop OS generally not even have an idea what an "app" is or who published it
Uhm, it does know which distro package the file came from and what metadata is. Not that it is useful — but well, commercial app stores are full of things that under any reasonable definition (even if not the current legal one according to the non-enforcement practice) are openly malware, too.
But yeah, firejailing/nsjailing/something similar most of the things is a good idea.
On which CPU won't it have significant overhead comparable to process switch?
CHERI :-)
I think also AS/400.
CHERI is a CPU design not a CPU though, as far as I can tell!
The distinction is unfortunately relevant because of my second point that ensures that all available performant hardware is constantly lying garbage.
do you have any resources about Windows isolation? To be honest, I'm not aware of anything besides UAC/firewall settings, which clearly do have their counterparts on linux and I was pretty confident windows and linux are pretty much on the same level of bad
My understanding is that if you use an MSIX installer you can scope the use of the Credential Manager to your application to get secure storage.
Note that MSIX secure storage protects the app from other sandboxed apps, not the system as a whole. Any unsandboxed app running as the user (which is most apps) can access the sandboxed apps' storage.
This is the same as with Flatpak on Linux: sandboxed apps are protected from each other, but not the host.
Really? Sometimes I find it hard to imagine that things would really be as stupid as in reality.
As far as I’m aware, in terms of general hardening https://github.com/HotCakeX/Harden-Windows-Security is the best tool to use. It also makes it easier to implement AppControl policy, which turns Windows into a deny by default (don’t let code run unless it’s explicitly allowed) environment. https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/appcontrol
first link seems i teresting, but I was curious more about the defaults what make Windows "more secure" surely, you can harden desktop linux as well, probably to the same level using selinux, cgroupsv2 (and related stuff), containers and limiting capabilities e.g. with systemd
To my understanding, which is "more secure" by "default" is difficult to impossible to accurately measure. The terms are simply too vague. From what I've heard, Windows just has more resources to lock it down, and the main issues are the fact it supports every optional feature since 1990 out of the box. Linux, on the other hand, in theory can be secured, but no one has done the necessary work with things like SELinux to fix the architectural flaws that (for every "normal" distro) enable one application to get anything in userspace. Based on vibes I think a malicious app on a Windows desktop could do similar things as on Linux, but I'm no expert on the subject. https://secureblue.dev is the only project I know of doing significant desktop Linux hardening, and afaik they hold this take generally too.
tl,dr: the ceiling is more measurable than the floor.
Ransomware has been the single greatest driver of cybersecurity stance for companies. Humans are just really bad at considering and preventing damage before it happens, so to a certain degree, high profile but low damage incidents are generally a good thing on the whole.
And, in addition, we've normalized granting random (and not-so-random) third-parties access to run things on our computers. In the name of security, even!
We need to wake up.
Our industry needs to wake the fuck up.
Are you sure that "our industry" is on some level aware of this? To me it often seems like the reaction is more of capitulation stance. This has multiple reasons, a big one being that in this industry if you take care (not just about security per se) you will usually be outperformed by people who don't.
And given from what one hears about the aviation industry, etc. it seems that our industry isn't alone with these issues.
Even being hacked, even being hacked or down due to a third party business rarely changes things. Very often the result is between "shit happens" and "yay, I don't have to work until it is fixed". And seeing how these issues scale really well it would theoretically be clear who does a better job, by picking those couple of unaffected ones.
However none of these happens, so people accept "private, sensitive data" to be leaked on a regular basis, usually until it really physically causes them harm. But also if everyone around you is affected as well - which often is the case - it's easier to normalize it. If you do what everyone else does and it bites you it's not your fault, shit happens, if you do something different and something bites you everyone will point at it. See Facebook and identity theft or simply burglary for sharing you are gone vs having an open wifi that someone abuses. Both can be silly because they make it more likely, one is accepted the other usually isn't.
I agree with you, but I worry that the wake up will be of little to no consequence. Also because something like this isn't a first. Supply chain attacks are common and while people sometimes think that maybe they'll try to use some dependencies the next day they put all their trust into what ever OpenAI spits out that day.
I agree. This issue was brought up in the Nix community sometime back, suggesting some standardization of sandboxing, but the reaction of a few community members was childish and borderline malicious. Sandboxing, à la bwrap or Firejail, was dubbed "inconvenient".
Personally, I think it's insane to run software with full access to the network and filesystem. Defense in depth is very valuable. If some package is compromised, sandboxing minimizes possible damage. I wonder how many breaches need to happen to push the status quo toward a role-based access control model.
It would be interesting to see a web of trust model for reviewing AUR packages, maybe combined with a cooldown for recent updates. I'm imagining a system that, when I install or update an AUR package, gives me a choice:
Cooldown might technically be incompatible with Arch's policy of always updating all your packages together—but then again, AUR packages don't come with official support anyway.
The problem is that even if the original maintainer was known and you verified the package someone could come in, orphan the package due to inactivity and then modify it to be malicious without you knowing any better.
I believe a better solution would be to get rid of that silly system entirely and have per-user namespaces like what COPR does.
KDE dropped AUR from its own build pipeline a week ago, I think in response to the last version of this attack.
That was just added bonus. Main reason, if I recall correctly, was the AUR stuff often broke our build pipeline. I don't know how or why, just commenting as someone who followed discussions around it.
Edit: this concerns just KDE Linux, i dont think we use(d) AUR anywhere else
Been several hours, and the NPM package is still up: https://www.npmjs.com/package/atomic-lockfile
It took another 15 or so hours after you posted this but it seems to be pulled now. "Security holding package" The link to an advisory / disclosure doesn't get you anything.
Entirely forseen problem. Open contribution software repository that people automate using (despite saying that it's bad to do so), don't moderate effectively (deflecting that responsibility to themselves), overuse (because there's so much stuff in the AUR that should really be main packages that you just need to use the AUR on any real arch setup), and without a 3-day delay on new packages on any of the major clients by default or anything like that.... AND people have noted all of these problems for years but nobody's picked up the problem and gotten anywhere addressing it, AND this isn't even the first time (not even the first time this year), it's just the first time it's hit so broadly.
I'm saying this as an arch user and evangelist, not a hater.
I know that actually solving the problem is going to take a lot of time and effort and be disruptive, but there's a bunch of bandage solutions that would genuinely significantly improve the situation and only take a couple days or weeks of effort to deploy (like I said about client-side delays for most users on pulling in too-recently-updated AUR packages, which would of course have to be overrideable). W/r/t security, perfect is always the enemy of the good, you want several lines of defense and putting up the easy defenses doesn't take the spotlight away from the more important hard ones.
people have noted all of these problems for years but nobody's picked up the problem and gotten anywhere addressing it
How much of this is due to values/culture?
Addressing the security concerns, in practice, might alienate and be rejected by a community that values breadth and recent updates.
The developers that care might have moved to an ecosystem that's already more aligned with their interests.
I moved from $OS_A to $OS_B because though it is more immature in many ways, the fundamentals and the values behind the community are more aligned with the things I care about. Changing $OS_A to look more like $OS_B didn't seem tractable, and isn't the type of problem I wanted to work on.
I don't think that's it really. Did you move to an OS because the other one allowed you to install random software off the internet, because that's what AUR is. Actually just in a more secure way, since there is a good way to use gpg signatures in there. There a standardized format and it's a lot easier to verify stuff. But the whole concept of AUR is random stuff off the internet that isn't officially maintained.
So because of that I'd srgiey it's on the same level as getting something off the official forum it mailing list about third party packages. Would you call their project immature for this? In that case I'm curious of what OS you use.
Use this small script with the aur_pkg_list.txt file to check if any of your installed packages are affected:
installed_pkgs="$(yay -Qq)";
grep refs aur_pkg_list.txt | awk -F/ '{print $4}' | tr -d ')' \
| while read -r pkg; do \
echo "$installed_pkgs" | grep "^$pkg\$"; \
done
Semicolons included so you can easily make it a one-liner :-)
Sorry but I can't pass up an opportunity to use comm:
comm -12 <(yay -Qq | sort) \
<(awk -F/ 'NR > 1 {print $4}' aur_pkg_list.txt | tr -d ')' | sort)
came to write the same thing. I started with sed instead of awk | tr
sed -E '/#/d; s:.*origin/|\)::g' aur_pkg_list.txt |
sort |
comm -12 - <(pacman -Qq|sort)
Notably the for loop version doesn't catch a package that I do see with comm ( python-jsmin for me :( )
EDIT: At least for this package, I'm probably safe -- installed years ago
pacman -Qi python-jsmin | grep Install\ Date
Install Date : Thu 15 Aug 2024 07:40:51 PM
Seems to match partial strings. e.g. ktea matches kteatime.
I think this one works though
grep refs aur_pkg_list.txt | awk -F/ '{print $4}' | tr -d ')' | while read -r pkg; do
echo "$installed_pkgs" | grep "^$pkg\$";
done
Context for non Arch users. AUR is this party community packages. And it's essentially a more formal way of where other distributions go the route of "get that package randomly off the internet". So this is kind of what you would expect.
It's not really a surprise It's about as related to Arch as a random.deb file is to Debian or Ubuntu. It's just a nicer flow to do exactly that thing and you can for example say you only trust signed packages of that one maintainer and so on.
But it's still essentially the equivalent of someone posting that great new package/script on an official forum/mailing list/pastebin.
Arch does warn a lot about that fact.
This isn't to defend anything and I think it's shocking how common is is to use AUR blindly and I think the lack of much common software is part of the reason.
But yeah just some context. The problem is a bit how convenient it is to do that. A bit like adding third party repos to and installing third party packages in other dustros.
The whole point of AUR is that they aren't officially verified/officially maintained so being shocked they are not is a bit missing the point. Again would be the same if someone made a list of all available third party software/install scripts/binaries for any other distro.
Yes, but this whole point is moot because Arch is practically unusable without the AUR.
Completely agree with that. That's really sad about Arch. It feels like without AUR there would be more official packages with more quality control.
Quite the consequence, of some tools meant to help people who want to install software not part of the official project.
What? I don't understand that take at all.
I have some AUR packages installed on my system, but I don't actually like using the AUR that much so there's not too many. The ones I do have are all of the kind where it was a convenience to use them (after reading the PKGBUILD top to bottom) and I could have just downloaded and installed that software myself.
This must be bad news for Omarchy users. Doesn't it just broadly enable AUR with no warnings?
Here is a direct link to the malware analysis for anyone interested: https://ioctl.fail/preliminary-analysis-of-aur-malware/
It was only listed in mastadon post at the very end.
Not at all surprising. AUR is a great example how big red blinking warnings about how you are running code random people give to you isn't something that people will care about. Basically the equivalent of Microsoft's popups.
The only way to prevent this is forbidding random people from publishing random code on the internet or preventing people from doing that. Not even Apple with their very closed ecosystem seems to manage that. So good luck with that!
What's worse is that even IT professionals do that, on their dev machines and servers. And to a certain degree companies encourage that. Wondering how long it will take until people find creative, reliable ways to inject malware into LLM output.
This might have been going on for a while. This email from 18 days ago suggests that a similar payload was used, but it seems like the malicious commits have been removed from the repo outright.
Related: is there a good comparison of the supply chain security postures of popular Linux distributions? Most articles I've found so far look like covert marketing or AI slop. Maybe I just need to research this myself...
The depressing part is that, as much as I love the ideals of community development, supply chain worries have me looking closer at siloed (or even proprietary!) options.
Related: is there a good comparison of the supply chain security postures of popular Linux distributions? Most articles I've found so far look like covert marketing or AI slop. Maybe I just need to research this myself...
https://slsa.dev/ defines security levels for a project's supply chain security posture.
I personally don't use SLSA adherence to judge things, but it does attempt the address the problem you're experiencing.
Flatcar documents their adherence to this in https://www.flatcar.org/docs/latest/reference/supply-chain/ and is built around using OCI containers. OCI containers backed by the Linux kernel have security limitations, but less than a typical AUR/Deb/Nix binary.
Most of the compromises I hear nowadays are through npm (which is not going to be safe on any platform) and now if I understand right AUR is a sort of unofficial extra repository for Arch, not a regular distro repository. I think I have heard of Arch users saying the AUR is dodgy for years, but I don't know it intimately.
Myself, I am doing more in unprivileged VMs, particularly development that pulls down packages from npm, PyPI, crates.io et al.
If it helps, incus is the tool I use for managing these (it supports both containers and VMs with a --vm flag).
if I read the post correctly, what happened is that packages were orphaned (which anyone can do if maintainer is unavailable for a surprisingly short period of two weeks) and then adopted, although I’m not sure what the procedure for that is. after that, I think, you can publish updates for the package without any review?
if that’s true, I feel like this policy is way too lax, which allows for this kind of large-scale attacks. for comparison, in nixpkgs, another massive software repo, users without a (comparatively rare) “nixpkgs committer” bit can only merge automated package updates, and anything else requires a committer approval. this still feels too lax, and nixpkgs has its share of security issues, but at least it doesn’t allow for pushing hundreds of packages silently.
The AUR is intended to be by users for users and so there is little to no oversight or accountability which is why this isn't the first time this happened.
The intended flow is that you download and build an AUR package yourself however most people use AUR helpers now which automate this process completely.
And even these helpers usually per default are very much like "DO READ THE SOURCE CODE AND BE ABSOLUTELY SURE THAT'S WHAT YOU WANT!!!1111", often defaulting to displaying the package's script/manifest and so on.
Sadly Arch Linux's official package repository is not the biggest and it can be surprising that something doesn't have an official package yet and the convenience these tools offer might contribute to the fact that while many know how to package software for others, there aren't all that many people maintaining official packages.
yeah, I understand that the idea behind AUR is that it’s a scary dangerous place you should think twice before using, but given that Arch’s official repos are quite lean, most desktop installations end up having stuff from AUR. it might be good to revisit this idea and maybe enforce some stricter standards.
Time to make write permissions to AUR invate-only and/or ban anything that has to do with npm?
How much of this is because of Github/NPM being much worse no security than other package registries?