Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • There are automated scripts to check if the infected AUR packages are installed on your system:

    https://forum.endeavouros.com/t/malicious-aur-checkup-script...

    https://github.com/lenucksi/aur-malware-check

  • The funny thing is: with FOSS you know what's going on attack-wise as they are transparent , but there must be huge upheaval in the closed source (e.g. MS) software that is just kept quiet by stock-price-chasing executives.
  • Fantastic and anti-sensationalism write-up from LWN, as usual. They continue to deserve my monies.
  • I'll note that OpenSuse also has Packman which a shitton of people enable (for codecs), has also 'one namespace only' an looser policies than the main distro.

    I do not think this something you can escape by switching distro.

  • Packman is more akin to rpmfusion, than AUR. OBS is the AUR equivalent for OpenSUSE.
  • Yes, the only reason this isn't happening in other distros is simply popularity.

    Namespacing is the solution, and as mentioned in the article some ditros do indeed have namespaced user repos, like Fedora's Copr. The trust model of a flat namespace user repo is completely broken when the maintaining user can change at any moment.

    by cqz
  • I use Gentoo. You have to specifically install "overlays" and every package maintainer would make their own overlay. You can't easily take over an overlay without the original person's permission.

    That being said, still one namespace. Once you add an overlay it can replace any package it wants.

    It's also Gentoo so too hard for most people to figure out.

  • Zypper at least has a notion of "vendor", so you can arrange things so that only the handful of packages you care about will actually come from Packman.

    Ubuntu actually has first-party repositories with proprietary codecs.

    Nixpkgs is a pretty comprehensive monorepo of packages with a more normal review process than the AUR, and it includes non-free software as well, plus the model with flakes for third-party stuff is that you trust individual publishers for their little repos rather than one giant grab bag repo of unreviewed content like the AUR.

    RPMFusion for Fedora kinda has a similar profile, in that it's a shared repo for various things unsuitable for the main one, but it follows more or less normal Fedora packaging and review standards, doesn't it?

    Supply chain attacks are possible everywhere and some distros have particular weaknesses, but the AUR really is pretty much uniquely bad here.

  • I love the smell of npm install malware in the morning.
  • Yes, feels like in those cases npm and bun are not far away. Coincidence?
  • The AUR is effectively a pastebin for PKGBUILD files.

    Some people (many of which don't even use Arch itself) have been treating and advertising it as something different. It's not a software distribution method meant for normal computer users.

  • And for those that aren't aware, a PKGBUILD file is just a bash script.
  • Note that the AUR attacks were part of the larger miasma worm campaign, gradually trying to gain more control through various package ecosystems since the RedHat prototype campaign.

    Mitigation Tool: https://github.com/cookiengineer/antimiasma

    Blog Post with details: https://cookie.engineer/weblog/articles/malware-insights-mia...

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

  • Humble 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 if there is any?

    I haven't run an antivirus since I last used Windows 20 years ago.

  • You might start with ClamAV and something like Little Snitch.
  • > 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.

  • 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 computer. But then those could be infected too, and so on.

    Ultimately I'd say it depends on your risk profile, but using something to actively approve/deny network connections on your local machine, is a great start that'd defeat most of these simpler "exfiltrate information ASAP" malware that seems popular at the moment.

  • Devil's advocate, except partially serious.

    This is a good thing, because the warning about checking everything you download from the AUR, which has always existed, is now actually "enforced". People respond to consequences.

  • In case anyone missed it, the latest version of yay (v13+) supports being able to skip recently added packages through its new Lua extension system https://jguer.github.io/yay/lua.html#upgrade-selection-hooks. You can control the threshold since it's just user configuration now.

    A bunch of common yay commands also return back the last updated time of a package thanks to https://github.com/Jguer/yay/pull/2846.

  • Hope Omarchy will make that a default:)
  • The thing is that hook is not enough: `UpgradeSelect` only applies to `yay -Syu` so it only filters the upgrade list.

    Nothing protect you from a `yay -S foo` install and its dependencies. So this is not a guarantee or enforcement of a minimum release-age.

    Actually writing this reply I went ahead and pointed that out in an issue at: https://github.com/Jguer/yay/issues/2883

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

    by jchw
  • I don't know how long will it take to attack also flatpak/flathub and snap stores as well.
  •   > 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`
  • > 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.

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