[HN Gopher] Firefox-patch-bin, librewolf-fix-bin AUR packages co...
___________________________________________________________________
Firefox-patch-bin, librewolf-fix-bin AUR packages contain malware
Author : rrampage
Score : 102 points
Date : 2025-07-18 17:48 UTC (5 hours ago)
(HTM) web link (lists.archlinux.org)
(TXT) w3m dump (lists.archlinux.org)
| jabjq wrote:
| > We strongly encourage users that may have installed one of
| these packages [...] to take the necessary measures in order to
| ensure they were not compromised.
|
| How are they supposed to do that when you give them no
| information as to what the malware does?
| rwmj wrote:
| Did you install one of those packages? If yes, nuke from orbit.
|
| More interesting questions are:
|
| - Who was the uploader? A packager? For how long?
|
| - Do they maintain other packages?
|
| - What steps can be taken to ensure that a similar problem
| doesn't happen in future?
| gpm wrote:
| Per the Wayback Machine the username used was danikpapas. As
| far as Google and duckduckgo know these are the only packages
| theat username ever uploaded. Considering the purpose was
| crime it's likely that that username was "stolen" and the
| person using it on other sites wasn't the same as the one
| doing this...
|
| The AUR is arch's repository of untrusted user maintained
| read-the-source-before-installing packages. There's really
| not much that can be done to prevent similar issues in the
| future... because the whole purpose of the AUR is to allow
| random people to upload packages.
|
| Arch doesn't ship with any way to install AUR packages other
| than downloading the tarball and building them locally. Tools
| for installing the packages usually force you to read the
| PKGBUILD that controls the build process (including getting
| sources) before letting you build the packages. I.e. the
| reasonable steps have already been taken.
|
| Edit: firefox-patch-bin was first submitted to the AUR
| 2025-07-16 21:33 (UTC), so less than two days before removal.
| diggan wrote:
| They are/were AUR packages it seems, anyone can spend 2
| minutes and upload essentially anything there, like npm and
| similar. It's not necessarily a "maintainer" per se, as like
| the people who manage the packages in the proper Arch
| repositories, but entirely separate.
|
| With that comes the same warning as downloading random stuff
| from the internet and executing it, you need to carefully
| review everything before running/installing it, as you're
| basically doing a fancy version of "curl | bash" when using
| the AUR.
| gpm wrote:
| It says what the malware does, it's a remote access toolkit...
| It gives control of your machine to the malware operator.
|
| The malware operator could have done anything with that
| access... There's no way for the maintainers to know what was
| done on any given infected machine.
| sp0rk wrote:
| Announcements like this typically contain information that
| will help users identify if they were compromised, such as
| the name of files that are dropped or modified when the
| malware is initialized, startup entry names, etc. Obviously
| the person with remote access can get in and manually start
| doing things on individual machines, but that doesn't mean
| there aren't indicators present from the programmatic actions
| the malware took before that point or on machines that
| weren't manually accessed.
| akazantsev wrote:
| Expecting a complete malware analysis from maintainers is a
| tad too much. Their goal is to notify users as soon as
| possible, even if no other information about the malware is
| available.
|
| Also, an attacker may leave no traces by simply dumping the
| payload to /tmp.
| gpm wrote:
| In addition to the point about "not being expected to do a
| full malware analysis"...
|
| Assuming the malware doesn't clean up after itself, `pacman
| -Q firefox-patch-bin librewolf-fix-bin zen-browser-patched-
| bin` would tell you if they are installed... but if it did
| clean up after itself... how are the maintainers supposed
| to know what steps were taken to clean up given that it's a
| rat that could be running different steps on different
| computers...
| Shellban wrote:
| This is really scary for those who manage multiple things.
| I'm considering running a factory reset on everything from my
| router to my Steam Deck and remote server.
| gpm wrote:
| Uh... did you install these AUR packages? It seems quite
| unlikely you installed these on either a router or a steam
| deck...
|
| That said, if you did, yeah being hacked is scary and I
| feel for you.
| johnisgood wrote:
| I wonder if he even has any unofficial packages
| installed.
| Shellban wrote:
| I had the regular librewolf-bin package installed on a
| couple of my machines. It took me a bit of time to note
| that librewolf-fix-bin is something separate.
| johnisgood wrote:
| Yeah do not worry, you are fine.
|
| https://aur.archlinux.org/packages/librewolf-
| bin#comment-103...
| Shellban wrote:
| As @lillylizard pointed out, it turns out that these are
| new packages, not comprised existing packages like I
| first thought. Still, the nature of the hack is a Remote
| Execution, as you pointed out elsewhere, meaning the
| hacker could pull my router password from the password
| manager, or grab my SSH keys and log into whatever
| machine is listed in the known_hosts, or just mess with
| my Ebay account and the credit card saved on there. The
| hacker could in theory do literally anything I could do.
| akerl_ wrote:
| Sure, but only if you'd installed the affected AUR
| packages. Even if they were old packages, probably your
| SteamOS didn't install them from the AUR.
| Ancapistani wrote:
| It's ArchLinux. The user is expected to do their own due
| diligence.
| johnisgood wrote:
| And these packages are from AUR, they are not officially
| supported. AUR means Arch User Repository. You cannot even
| use Arch Linux's official package manager to install AUR
| packages either, you need an AUR helper ("makepkg" is
| sufficient though but it has limitations). These AUR helpers
| are not even official packages either. Not even yay:
| https://archlinux.org/packages/?sort=&q=yay.
| npteljes wrote:
| In case of any infection, the necessary measures are to take
| the affected machines offline, extract whatever data you need,
| and then wipe.
| heavyset_go wrote:
| Anyone have a copy of it that I can poke at in a virtual machine?
| techjamie wrote:
| You might be able to poke at the PKGBUILD on the wayback
| machine and see if the original sources work.
| mzajc wrote:
| The PKGBUILDs are not archived, but the package page does
| helpfully list its sources, one of which is
| https://github.com/danikpapas/zenbrowser-patch.git (same for
| all three packages). I would assume that's where the malware
| is, but I couldn't find an archive. Does
| https://www.gharchive.org/ keep this sort of data?
|
| ETA: According to a Reddit post linked elsewhere in this
| thread, the payload was a binary file downloaded by a python
| script in the repository. It has been uploaded to VirusTotal,
| but downloading requires a premium subscription according to
| their docs: https://www.virustotal.com/gui/file/d9f0df8da6d66
| aaae024bdca...
| lorenzohess wrote:
| Could there be programmatic ways to help users characterize the
| safety of the AUR packages they install? Perhaps a program that
| prints all URLs in the PKGBUILD and offers the option for the
| user to open them in the browser? Or which automatically shows a
| diff if a PKGBUILD is updated? Highlighting changes would make it
| easier for the user to determine if he should spend time
| exploring those changes for malware.
|
| One could go even further and list all new commits, making it
| super easy for the user to check them. Maybe even integrate an
| LLM to help? Maybe commits from non long-time contributors could
| be flagged?
|
| There has to be a way to help users programmatically review
| updates to their AUR packages. Even if most of them won't spend
| the time.
| IceDragon200 wrote:
| As one commentor pointed out, in Arch it's the user's
| responsibility to review any AUR packages BEFORE installing
| them (and I say this as an Arch user and AUR package
| maintainer).
|
| This particular issue is with a binary (i.e. pre-built)
| package, normally in Arch it's expected from an AUR package
| that you will build it yourself and most if not all packagers
| prompt you to review and or edit the PKGBUILD before it does
| anything.
|
| Basically you could spot something suspicious in a source
| package, not so much in a binary package.
| WD-42 wrote:
| This is exactly what many of the AUR helpers like yay and paru
| already do - ask you to review the pkgbuild diffs before
| installing or updating.
| porridgeraisin wrote:
| I like that idea of printing the URLs it downloads. Will help
| screen quickly if it's doing something malicious.
| Tharre wrote:
| PKGBUILDs are just bash scripts following a certain function
| and variable naming convention. Even if you could somehow parse
| it safely and extract the URLs of the 'source' array, any
| attacker can just simply put an obfuscated version of the
| malware URL into the build() function and download it there.
|
| AUR clients already show you the diff if you update a package,
| but note that this were completely new packages anyway,
| uploaded 2 days ago, so that doesn't really apply here.
|
| LLMs are useless for reviewing if something is malicious, their
| false-positive rates would be way to high. And even ignoring
| that you'd have to hide the LLMs code from the attacker or he
| can just check if his package is detected as malicious and
| modify it until it isn't. Not something open source projects
| are keen on doing.
| diggan wrote:
| > AUR clients already show you the diff if you update a
| package, but note that this were completely new packages
| anyway, uploaded 2 days ago, so that doesn't really apply
| here.
|
| The program I use for AUR (Rua) still displays exactly what
| you're about to build (as a git diff), before you build it,
| even if it's the first time/release. I'd assume all the other
| "AUR managers" would work the same way?
| Tharre wrote:
| They should all show you the PKGBUILD before building, yes.
| kiranet wrote:
| LLMs are also really easy to trick, as we saw in the GMail
| white-on-white text PoC just a few days ago...
| WD-42 wrote:
| As Arch seemingly explodes in popularity I'm afraid we'll start
| seeing more of this.
| yuvadam wrote:
| Is arch exploding in popularity? Because of Omarchy or
| something else?
| eddythompson80 wrote:
| The current iteration of SteamOS (the one shipped on Steam
| Deck) is Arch based. So a lot of non-linux users got exposed
| to it as their first linux distro. Especially with all the
| emulation guides and other random guides for doing "advanced"
| stuff to your Steam Deck by dropping in the Arch-ish desktop.
|
| Also anyone who wants to try "Gaming on Linux" needs bleeding
| edge kernel which is Arch's default setup compared to other
| distros.
| Phelinofist wrote:
| I think I saw posts on Reddit with XQC saying Arch is the
| best. I mean it is. And I use Arch btw.
| kwk1 wrote:
| An evaluation of what's best really depends on how one
| weighs different tradeoffs. For example, Debian and Arch
| are basically polar opposites in terms of two questions:
|
| 1) do you want an intermediary between you and the
| upstream? for example, to patch out telemetry
|
| 2) is it important that what you're using continues to work
| the same way so you can focus on your actual work?
|
| No answer to either is consequence-free, e.g. for 1), see
| the Debian SSH patch event, or for 2), if the answer is "it
| doesn't work", then that kinda forces one's hand.
| gpm wrote:
| There's also the significant caveat with 2 that it's only
| "continues to work the same way" until everything changes
| all at once because you now need to update to the next
| version of Debian.
|
| The "everything changing all at once" thing is what
| eventually drove me to arch (as the most popular at the
| time rolling release distro - and more stable at the time
| than debian sid), I'd personally rather have smaller
| breaking changes more frequently. Though it's probably
| less painful now to update debian versions than it use to
| be because things generally work better without
| configuration than they used to.
| ementally wrote:
| CachyOS (Arch based distro), no.1 on https://distrowatch.com/
| johnisgood wrote:
| > Blazingly Fast & Customizable Linux distribution
|
| I love Arch Linux, but please...
|
| (Arch Linux is already "fast" (depends on what you install
| for your DE, if any) and customizable.)
| ziml77 wrote:
| But their differentiation is that to improve performance
| they compile all the packages with newer instruction sets
| as the target as well as enabling more optimizations like
| LTO. And some are even optimized with PGO.
| johnisgood wrote:
| I find it odd to call a specific Linux distribution
| blazingly fast.
|
| Gentoo with make.conf (/etc/portage/make.conf[1]) having
| "CFLAGS="-O3 -march=native -flto"" means that Gentoo, a
| Linux distribution, is performant?
|
| [1] It is not a good idea to build everything with LTO or
| PGO enabled because not all packages support LTO / PGO
| cleanly. Do it on the basis of per-package.
| ziml77 wrote:
| I've seen claims of decent speed improvements when using
| CachyOS, though I can't say I've ever hunted down solid
| confirmation. I'm a bit wary of the project because I
| would have to put a lot of trust in them since they're
| rebuilding everything themselves and could easily
| introduce malware somewhere in there. (But I've been
| scared of distros before only to have it pointed out to
| me that some very well respected people are involved, so
| I could be worrying for nothing here too)
| LeoPanthera wrote:
| This is a slight aside, but CachyOS is a great example of
| the failure of Wikipedia politics.
|
| The "CachyOS" page was deleted[1], and replaced with a
| redirect to the Arch Linux page. But CachyOS is not
| mentioned anywhere on that page, nor on the "List of Linux
| distributions SS Arch Linux-based" page.
|
| [1]: https://en.wikipedia.org/wiki/Wikipedia:Articles_for_d
| eletio...
| diggan wrote:
| It links to
| https://en.wikipedia.org/wiki/Arch_Linux#Derivatives
| which indeed lacks any mention of CachyOS. Luckily,
| Wikipedia is free to register, and you can just edit
| pages you feel like could be better. Seems like you found
| the perfect first edit to make for yourself :)
| LeoPanthera wrote:
| I have a long Wikipedia history, but that is not the
| point. There _already was_ a CachyOS page, and it was
| removed. Why bother contributing stuff that will just be
| deleted again?
| VTimofeenko wrote:
| It might have been removed due to the editor's impression
| that CachyOS is not significantly different from Arch.
| With proof to the contrary the page may be restored.
|
| There are a lot of derivative(I don't mean it in a
| negative way) distors out there, not sure if they all
| need pages.
| diggan wrote:
| Most moderated spaces remove content that doesn't fit the
| community, Wikipedia does take that to the extreme but I
| still prefer that than the opposite extreme.
| f33d5173 wrote:
| It's an endemic issue on wikipedia, and even editing
| wouldn't fix this one instance, since someone can (and
| demonstrably already has) remove whatever you add later
| on. The issue is wikipedias preference for "deletionism",
| removing perfectly correct information for no
| particularly good reason. It's especially pernicious when
| it comes to short articles, which tend to get deleted
| with impunity, and redirected to sections of articles,
| which later get renamed, destroying the link, or removed
| altogether. Nothing can be done by any individual to fix
| this issue, since it comes from a wikipedia wide policy,
| which unfortunately is not one of the things that "anyone
| can edit".
| diggan wrote:
| I agree with most of what you wrote, but unless you can
| demonstrate that someone actually added CachyOS to the
| "Arch Linux-based" on the "List of Linux distributions"
| page and it was later removed, I'm not sure how much it
| matters how Wikipedia generally works.
| Hackbraten wrote:
| That's just a ranking of subpage hits per day. Not only is
| that easily gamed, it also says very little about how
| popular an OS really is.
| ASalazarMX wrote:
| The only thing I've seen Arch exploding in popularity has been
| memes. It's a fun distro for hobbyists, but too inconvenient as
| a daily driver.
| urda wrote:
| If Arch is too "inconvenient" as a daily driver, you might
| find yourself more at "home" on a Windows install instead.
| Shellban wrote:
| Well, Arch has (historically) been rather difficult to
| install from scratch, and requires a lot of Linux knowledge
| to get up-and-running as a daily driver. If one is
| installing it for the first time and misses something
| (which audio backend?), it can be rather frustrating down
| the line.
|
| There is a reason Ubuntu is usually the first distro new
| Linux users go to. For almost a decade now, installing a
| feature-complete Ubuntu setup is not much more difficult
| than reimaging Windows.
| zaruvi wrote:
| Can you elaborate why you think this?
|
| Personally I've been running Arch on my work machine for a
| few years now with very few issues. I'm not even very
| consistent with updates, and probably run them about once
| every 3 weeks on average. I have only had to manually
| intervene on a handful of occasions.
|
| I like it a lot because everything is always up-to-date. I
| don't face any issues with unsupported versions for tools
| like I have with Debian in the past. The rolling release
| model also saves me the pain of doing a "hard" OS upgrade,
| which often come with issues.
| mariusor wrote:
| I can't imagine what kind of a problem I would personally
| have to encounter to make me utter such a sweeping
| generalization with this much confidence. :)
|
| At least this guy has been using it as a daily driver (at
| home and at work) for at least fifteen years.
| bee_rider wrote:
| It this recent? I thought "I use arch btw" was more of a
| thing... 5 or so years ago.
|
| I switched away from Arch (to Ubuntu) as a sort of side
| effect of switching computers a couple years ago
| (desktop->laptop, though Ubuntu would "bring the batteries
| along" more conveniently). Ubuntu is fine I guess, but I
| really miss the stability of rolling release and the user-
| friendliness of not having too many built in programs.
| andrelaszlo wrote:
| I've been using Arch as my daily driver for over fifteen
| years. I'm not a fanatic, it just works really well.
| WD-42 wrote:
| This is just ignorant. I've been daily driving Linux since
| 2005. The majority of that time has been with Arch. Despite
| the memes, I've found it to be MORE stable than your typical
| Debian derivatives. It's funny to me that it took over a
| decade for people to come to the same realization.
| johnisgood wrote:
| FWIW this is AUR. These packages are not officially supported.
| AUR = Arch User Repository.
| nilamo wrote:
| Plenty of package managers (such as `yay`) install from AUR
| by default.
| johnisgood wrote:
| yay is a package manager that has been made for AUR. yay is
| not the official package manager for Arch Linux, pacman is,
| and it does not support AUR. yay is not installed on Arch
| Linux by default, its official package manager, pacman, is.
| AUR is for unofficial 3rd party packages, i.e. "use at your
| own risk". It has always been the case.
| IlikeKitties wrote:
| Yes, it is "use at your own risk" but most arch users
| just install from it without giving it a second thought,
| because availability of packages in the AUR is the one
| thing Arch is good at.
| Hackbraten wrote:
| > most arch users just install from it without giving it
| a second thought
|
| Citation needed.
| johnisgood wrote:
| N=1 but I rarely install from AUR and I have been using
| Arch Linux for decades. Using "yay" is akin to doing
| "curl | sh". You should inspect the PKGBUILD at the very
| least, and I do not believe "most users" is correct.
| diggan wrote:
| > most arch users just install from it without giving it
| a second thought
|
| I'm not sure that's true. Neither I nor most people I
| know who use Arch (granted, most of them are professional
| software developers) install software from the internet
| willy-nilly and without reviewing anything, if by AUR or
| "curl | bash", especially when on their main computers.
| akerl_ wrote:
| Those users are going to learn some hard lessons, either
| in this incident or a future one.
|
| Archlinux is a distro that's designed for the user to
| control their own system, and the AUR is clear about what
| it is and the nature of the packages in it.
| johnisgood wrote:
| Oh, and by the way, not sure how people miss these:
|
| > Warning: AUR packages are user-produced content. These
| PKGBUILDs are completely unofficial and have not been
| thoroughly vetted. Any use of the provided files is at
| your own risk.
|
| This is from
| https://wiki.archlinux.org/title/Arch_User_Repository.
|
| > Warning: AUR helpers are not supported by Arch Linux.
| You should become familiar with the manual build process
| in order to be prepared to troubleshoot problems.
|
| This is from
| https://wiki.archlinux.org/title/AUR_helpers.
|
| "yay" is one of the most common AUR helpers, it requires
| two confirmations from what I counted. One of them is to
| inspect the PKGBUILD file, the other one is just to
| proceed.
| bee_rider wrote:
| On one hand, the distro developers can't really prevent
| people from, say, hitting their computers with a
| sledgehammer or something. So to some extent, the users
| have to be trusted.
|
| But, maybe it would be best not to have "yay" available.
| Using something like AUR without reading the package build
| files is... pretty bad, right? And it is bad for the
| community, because if there is a convention of doing that
| sort of thing, it makes the AUR a good target for
| attacking.
| akerl_ wrote:
| Yay is a 3rd party package manager. The 1st party package
| manager does not interact with the AUR.
|
| Yay itself is in the AUR. You have to go out of your way
| to install it.
|
| The Archlinux docs on AUR helpers lead with a red
| warning: https://wiki.archlinux.org/title/AUR_helpers
| thedanbob wrote:
| > But, maybe it would be best not to have "yay"
| available. Using something like AUR without reading the
| package build files is... pretty bad, right? And it is
| bad for the community, because if there is a convention
| of doing that sort of thing, it makes the AUR a good
| target for attacking.
|
| I don't remember how yay works but paru (another AUR
| package manager) displays the pkgbuild file before it
| will install.
| heavyset_go wrote:
| Nearly all distros have this problem when it comes to packaging
| and distributing 3rd party software.
|
| Even if you're using an immutable distro, your KDE Plasma
| session can get hijacked if you simply use the built in wizard
| to install 3rd party desktop widgets, which is a right-click +
| single-click away on any Plasma destkop.
| mzajc wrote:
| Any clue what these packages were 'supposed' to do or why
| somebody might have installed them? Their PKGBUILD descriptions
| are copies of the respective browsers', not explaining the
| -patched part.
| Jorchime wrote:
| I wondered about the same thing. Not an answer, but my guess
| would be that it's just a new package and they hoped someone
| picked it up by accident? In that case, it was patched with
| malware :)
| Hackbraten wrote:
| They (or someone in cahoots with them) made at least one
| attempt [0] to lure readers of the Arch Linux subreddit to
| the malicious PKGBUILD.
|
| IIRC, the post was just a single paragraph, praising how they
| "found" the zen-browser-patched-bin package on the AUR and
| how much it helped them.
|
| [0]: https://www.reddit.com/r/archlinux/comments/1m30py8/aur_
| is_s...
| Vortigaunt wrote:
| Looks like someone archived the page of firefox-patch-bin[1]
| and the only thing that stands out about the package itself is
| that it's supposedly the "Extended Support Release." Besides
| that it looks like it's depended on by 183 other
| packages/metapackages. While that seems more interesting, there
| isn't an archive of all of those packages.
|
| [1]https://web.archive.org/web/20250718140411/https://aur.archl
| ...
| mzajc wrote:
| I saw the ESR part - I assumed the author (mistakenly?)
| copied firefox-esr's description. As for the dependents, it
| seems the malware package provided `firefox`, meaning all
| dependencies on `firefox` can instead be fulfilled by
| `firefox-patch-bin`. Perhaps the idea was to fool package
| managers into showing it as one of the alternatives.
| Tharre wrote:
| These 183 packages depend on "firefox", and the malicious
| firefox-patch-bin had a provides=( 'firefox' ) clause in it.
| That's why they all get listed on that page. The provides
| clause is useful when you have multiple packages for the same
| thing with different names, for example -bin and -git
| versions.
| jchoksi wrote:
| AUR packages are user-produced content i.e. packages built on
| their own machines.
|
| They have to be installed via "pacman -U package_file"
|
| Arch developers can code "pacman -U" such that it performs a
| VirusTotal scan before installation for each package.
|
| VirusTotal's API is free.
|
| - https://docs.virustotal.com/docs/api-scripts-and-client-libr...
| - https://docs.virustotal.com/docs/please-give-me-an-api-key -
| https://docs.virustotal.com/docs/consumption-quotas-handled
|
| Since it is end users who are doing the upload and virus scan
| check, there won't be a consumption quota issue with VirusToal.
|
| Lastly, "pacman -U" should flag failed VirusTotal scans to Arch
| Security.
|
| Arch's pacman and Flathub's flatpak package managers should be
| the last line of defence when installing untrusted packages by
| end users.
| akerl_ wrote:
| Is this accurate? My understanding is that the AUR does not
| host binary packages. It hosts pkgbuild files, which contain
| config and scripts that a user has to build on their own
| machine in order to install. The malicious code here is fetched
| as part of those scripts.
| johnisgood wrote:
| No, it is NOT accurate.
|
| Pacman cannot be used to download, compile, or install AUR
| packages. You need the PKGBUILD file and use "makepkg -si" at
| the very least. If you want AUR packages, you'd install a
| package manager (in this context referred to as AUR helper)
| like "yay" that supports both official and unofficial (i.e.
| AUR) packages. FWIW AUR helpers are not even official
| packages, not even "yay" which is a popular one. You need to
| go out of your way to install "yay" (although it is one
| command away before, i.e. very easy).
|
| TL;DR: Pacman does not download, compile, or install packages
| from the AUR, nor does it resolve their dependencies.
| "makepkg -si" builds and installs a package based on the
| PKGBUILD file, or use an AUR helper that overcomes the
| limitations of "makepkg". AUR helpers make it easy to install
| AUR (i.e. unofficial) packages.
| akerl_ wrote:
| And even with 3rd party package managers like yay, the
| package manager is pulling the pkgbuild definition locally,
| running makepkg for you, and then installing that.
| johnisgood wrote:
| Yeah, it is called an "AUR helper" officially because it
| just automates these processes for you.
| BearOso wrote:
| And yay warns you before anything happens and prompts you
| to review the PKGBUILD files and any patches for this
| very reason. So there are at least two "are you sure?"
| confirmations needed before even building anything.
|
| This is a situation where you have to go out of your way
| and be naive to be affected. You simply can't protect the
| user from everything.
| OsrsNeedsf2P wrote:
| Between false positives, high QPS, and the fact malware devs
| would then test against Virus Total, is this useful?
| Tharre wrote:
| First of all, this is incorrect, the checking would have to
| happen _before_ even building the package since malware is
| already being executed at that point.
|
| But more importantly this is a _terrible_ idea in regards to
| privacy /infosec. I do not want packages I build and install
| myself to be uploaded to a 3rd party website.
|
| And for what benefit? 99% of new malware won't be detected
| anyway, and once it is known it is way more effective to just
| remove the offending package from the AUR.
| jchoksi wrote:
| > malware is already being executed at that point
|
| To ensure reproducible / clean builds, I thought makepkg
| would always be run in a sandbox/chroot environment. The
| damage done would be localised to that sandbox.
|
| > this is a terrible idea in regards to privacy/infosec.
|
| Ok. Devs could setup an option to pacman -U which allows it
| to bypass VT for privacy sensitive people. This just puts the
| onus on you to not ensure you aren't installing malware. The
| default Arch user should still be protected while allowing
| for your privacy needs.
|
| > 99% of new malware won't be detected anyway, and once it is
| known it is way more effective to just remove the offending
| package from the AUR
|
| Its too late then. People are already affected.
| akerl_ wrote:
| It seems like you may not be familiar with Arch?
|
| No, makepkg doesn't run in a sandbox. The system tries to
| stop you from running it as root, but otherwise all
| validation of the trustworthiness of the pkgbuild and any
| sandboxing of the build process are left up to the user.
| This is part of why pacman, the 1st party package manager,
| does not fetch from the AUR.
|
| Likewise, it would be generally against the Arch ethos to
| have the default behavior of the package manager interact
| with a 3rd party service. If a user wants that action,
| they'd need to perform it themselves.
| Tharre wrote:
| > To ensure reproducible / clean builds, I thought makepkg
| would always be run in a sandbox/chroot environment. The
| damage done would be localised to that sandbox.
|
| makepkg runs in a fakeroot environment, but this is not a
| security barrier. There is also support for building inside
| systemd containers, offering at least limited security, but
| most AUR helpers don't use that yet.
|
| > Ok. Devs could setup an option to pacman -U which allows
| it to bypass VT for privacy sensitive people. This just
| puts the onus on you to not ensure you aren't installing
| malware. The default Arch user should still be protected
| while allowing for your privacy needs.
|
| You mistake the target group of Arch Linux. Users are
| expected to read the documentation and to know what they're
| doing. Protecting users from themselves at the expense of
| those who know what they're doing is not what Arch is
| about.
|
| > Its too late then. People are already affected.
|
| That doesn't make sense, it's too late for people if new
| malware isn't detected by VirusTotal as well.
| tojumpship wrote:
| > Devs could setup an option to pacman -U which allows it
| to bypass VT
|
| Goes against the very nature of the distro. I very rarely
| see assumed defaults in Arch, and they are almost always
| opt-in. Mind you, you need community provided helpers to
| automate AUR building, its that barebones and I'm sure
| there are people who manually build / use custom scripts to
| build every package.
| icar wrote:
| Just create a pacman hook before install that uploads the
| package there and aborts installation if necessary. Probably
| skipping repo packages is a good idea otherwise you're gonna
| spam the API each update.
| diggan wrote:
| > Arch developers can code "pacman -U" such that it performs a
| VirusTotal scan before installation for each package.
|
| AFAIK, VirusTotal only flags known malware/viruses, any
| new/"looks-to-be-new" stuff wouldn't be flagged until they've
| picked it up, and once someone would have picked it up, it
| should be removed from the AUR anyways. So you'd have at least
| one user (most likely more) getting infected first, and once
| detected more users wouldn't be able to install it regardless.
| jchoksi wrote:
| > So you'd have at least one user (most likely more) getting
| infected first, and once detected more users wouldn't be able
| to install it regardless.
|
| This is where your and my intentions differ. I don't want the
| average Arch user to be infected when it can be prevented
| because the malware is known about.
| diggan wrote:
| > I don't want the average Arch user to be infected when it
| can be prevented because the malware is known about.
|
| Me neither, my argument would be that VirusTotal won't stop
| the initial users from getting infected, so not good enough
| in my mind.
| defraudbah wrote:
| i installed a lot of cra* from aur in the past, wouldn't be
| surprised if i got a malware somewhere. Strange thing, I don't
| think open snitch would even help in such situation..
|
| and official repo does not have enough packages to run arch :\ I
| don't want to go back to ubuntu
| gus_ wrote:
| I haven't taken a look at the malware, but it seems to download
| files from the Internet so it should have warned you to
| allow/deny the outbound connections.
|
| It'd be nice to test it with a sample of aur package/malware.
| Barrin92 wrote:
| There's always been this security theater of people recommending
| arch because they "don't trust the companies" or Canonical or
| what have you but frankly I'm surprised this hasn't happened
| sooner. Well or maybe it has and we don't know.
|
| Running random binaries on your computer uploaded by some
| anonymous dude has to be the equivalent of buying heart medicine
| on craigslist. And because Arch is so barebones to begin with the
| AUR is very popular, you see a lot of arch users using it.
| h4ck_th3_pl4n3t wrote:
| Arch bugfix time is usually within 24 hours.
|
| Not a single enterprise distro even reacts within that
| timeframe. OVAL advisories are weeks, sometimes months later.
|
| As long as you don't have a virtualization approach similar to
| QubesOS, any linux distro will not fix this problem. Because
| that's not how separation of concerns works in the POSIX
| system. You need to have separate users for each and every
| program to isolate them, and that is practically unfeasible.
| WD-42 wrote:
| How exactly is Arch barebones? It basically ships with
| everything I need, more than most distros (Zed and Discord are
| good examples). I don't even need to use the AUR.
| Barrin92 wrote:
| Just by taking a glance at the most popular packages
| (https://aur.archlinux.org/packages)
|
| Pretty much every browser that isn't Firefox including
| Chrome, VS Code, most proprietary software like Slack, Zoom,
| Spotify, many vpn clients and password managers, a lot of
| them seemingly not published by the companies in question.
|
| All of those ancillary password, vpn or security related
| products who aren't going to be in the main repo because they
| have proprietary elements and also rely on random people
| seems particularly bad. And there's a lot of software in that
| category.
| WD-42 wrote:
| And what distro does package those?
|
| That's what Flatpak is for. If you must install crappy
| proprietary software, at least get an official package from
| the developer.
| BearOso wrote:
| Chrome is in the main repos as chromium. VS Code is the
| "code" package. I don't know what vpn clients you're
| referring to, but networkmanager is built-in and has
| support for openvpn and wireguard.
|
| Yes, proprietary software has to be installed separately,
| but for things like cloud password managers you're already
| putting your trust someplace else. You're also not likely
| to be hit by out of these flyby attacks, because the stuff
| people want is popular and has people watching it
| constantly and reputable people maintaining it. These
| patch/fix packages are suspicious looking and probably
| didn't have a single person touch them.
| christophilus wrote:
| Man. I am on Fedora, but I do have a handful of copr packages
| installed. (Copr is the Fedora analogue of the AUR.)
|
| This makes me nervous. I guess it's time to do some audits.
| lilly-lizard wrote:
| it should be noted that these are different from the popular
| librewolf-bin (513 votes) and zen-browser-bin (176). with this in
| mind it's cool that these got identified only 2 days after being
| uploaded. I wonder if the reporter actually intended to install
| it or just reads the PKGBUILDS of new packages to be a good
| samaritan...
| Shellban wrote:
| I only just noticed the difference myself. That was a scare!
| npteljes wrote:
| I wonder how popular these packages were. Librewolf and Firefox
| sure are popular, so this sounds scary, but for example searching
| for "firefox-patch-bin aur" yields no results, aside from sites
| talking about how it contained malware.
|
| My impression is that the malice was spotted timely, and not many
| people were affected. Which is a pretty good thing!
___________________________________________________________________
(page generated 2025-07-18 23:01 UTC)