Malware Found in Arch Linux AUR Package Repository (bleepingcomputer.com)

An anonymous reader shares a report: Malware has been discovered in at least three Arch Linux packages available on AUR (Arch User Repository), the official Arch Linux repository of user-submitted packages. The malicious code has been removed thanks to the quick intervention of the AUR team. The incident happened because AUR allows anyone to take over "orphaned" repositories that have been abandoned by their original authors. On Saturday, a user going by the pseudonym of "xeactor" took over one such orphaned package named "acroread" that allows Arch Linux users to view PDF files. According to a Git commit to the packag's source code, xeactor added malicious code that would download a file named "~x" from ptpb [dot] pw, a lightweight site mimicking Pastebin that allows users to share small pieces of texts.

Comments

A rare photo of a malware author being born.

[AlanObject]

From the looks of it the bad actor xeactor didn't have any expectation beyond finding out if his little trick would work or not.

On the other side this could be a case study about the immune system that open source provides.

Re:Moar Fake News!

[phantomfive]

No one ever said that open source was perfect. But consider that we are talking about one piece of malware......then notice how much malware has been found in the Apple store and the Android store.

Why so little malware?

[Anonymous Coward]

I'm more interested in why there is so little malware. I would have expected lots of malware without any packages needing to be hijacked.

Re:Why so little malware?

[jmccue]

I kind of wonder this also. I do not know how many package maintainers in ARCH or how it works, but with the amount of packages available in some distros these days I guess I should not be surprised.

Sad that distro maintainers may have to vet maintainers now, adding an additional burden. But as a user we should always be careful with non-core packages.

Re:Why so little malware?

[Anonymous Coward]

I'm more interested in why there is so little malware.

How many packages (maintainers) are actually already compromised, waiting for the trigger to be pulled to push out the big fail? How would you know?

Re:Why so little malware?

[Anonymous Coward]

It needs another malware program to run. Something called systemd.

Re:Why so little malware?

[XArtur0]

First: We don't know if there is any more until we find it. Therefore: The System is as Secure as an Open Door.

Second: Malware authors target platform that matter, i.e. Windows (large user base), RedHat (users are companies), Linux Kernel itself (large user base, governments, companies, etc...)

And Lastly: There is nothing worthwhile to steal from unemployed neckbeards (although I like Arch, and I work over 14 hrs a day the days I don't attend university).

Re:Why so little malware?

[BrianMarshall]

I made this comment in the story that is about to roll off the bottom of the page...

At home, I have used Linux - first Redhat, then Fedora - since about 1999. I have never used any sort of virus/malware scanning software. As far as I know, I have never had any malware. I don't know how common this is.

Re:Why so little malware?

[nnull]

Because many arch users actually check the install scripts in AUR and don't just install yaourt. *wink*

Re:Why so little malware?

[AHuxley]

Its a lot of work for number of users per distro. To look at free work on a distro on the users computer?
With other consumer OS the ability to "consume" would be of interest to malware.

Re:Why so little malware?

[Opportunist]

Effort vs. effect. And that ratio simply sucks when you consider the market share of Linux, and then that this market share is also again split up between the various distributions.

Hence invading a distribution repository isn't that helpful if your goal is what most untargeted malware attacks are aiming for: Wide distribution. It's different if you have a specific target in mind, like a particular government facility, but then you would probably be rather targeting one of the larger distributions, not Arch.

Re: Why so little malware?

[Zero__Kelvin]

I see you are confused about how software and Open Source work, even though you are posting on a story of it actually happening. Each individual doesn't have to inspect their own copy. Just one qualified person is all it takes, then everyone benefits from the improved security that results from identifying and correcting the issue. I know ... I know... this technology stuff is *SO* confusing!

Re: Why so little malware?

[Zero__Kelvin]

People aren't going to waste their time when they know any malicious code will be discovered quickly and there is a high chance their name will be spread far and wide on the blackball circuit.

Re: Why so little malware?

[hairyfeet]

Except there is a fatal flaw with your argument which TFA shows, which is the whole thing is based on an "is ought" fallacy. You ASSUME there OUGHT to be someone who 1.- Has the years in IT security to spot obfuscated malware code, 2.- Has the time to vet every single package every time it is altered, and 3.- Is able to do that for every single package available before any of those packages are updated but just because you again ASSUME there OUGHT to be someone or multiple someones doing that does NOT mean there IS someone doing that.

Hell if you think about it even for a minute you'll see how foolish the entire argument is, I mean how many packages are in your average distro? Now how many packages are in your average repo? And as we all know shit is changing in the Linux world constantly so how many of those packages are getting changed in any given month? If any of you has looked at the code for the obfuscated C contest you'll know its not hard to hide malware code in such a way its DAMN hard to spot...now are you REALLY gonna sit here and argue that someone is paying some huge team of top IT security researchers to sit there 8 hours a day doing NOTHING but vetting your favorite distro? Really? Remember this isn't something you can get some volunteer to do as well written malware code isn't gonna be at all easy to spot and it can even be broken up so that pieces of it is in multiple packages, it takes coders with years of security exp to spot the signs and those guys? Yeah they ain't cheap, not at all.

Re: Why so little malware?

[Zero__Kelvin]

I guess the irony escapes you that you are claimimg something doesn't work in a story about it actually working. Nobody said Open Source will be free of bugs and malware; the fact is that Open Source leaves open opportunities to get better that closed source doesn't have. This is just one example of the Open Source model working in a way closed source simply can't.

Re: Why so little malware?

[hairyfeet]

Heartbleed ring ANY bells? That was exploited for God knows how long before anybody got hit with a clue bat (in fact last I checked there are STILL servers out there with the exploit unpatched) but again because everyone ASSUMES the code is being vetted that bug was able to stay in there for decades.

Then there is the infected Quake 3 Arena that stayed in the Ubuntu repo for over a year, the KDELook trojan that lasted nearly 2 years, hell i could go on all day listing times where nasty shit got completely overlooked because everyone assumed that SOMEBODY was checking this shit...but they weren't and as I pointed out just a teeny tiny bit of logic blows the entire premise to shit.

But lets here it Einstein, because I'm sure we'll all find the insane logic hoops you'll be jumping through REALLY funny...explain to us where these magical security IT teams are coming from to vet every single package on the repo of your choice because as I pointed out unless they have years of exp spotting obfuscated C code is DAMN hard, who is paying the many millions to have them do nothing but check all that code, and how they are able to check the hundreds if not thousands of packages that change in any given year on your average distro.

Because I'm willing to bet my last dollar that if you look at who is accessing the code for the boring bits and bobs that make up your average distro, all the dull parts from the calendar function to the googly eyes to the code that controls the wallpaper, that the only ones accessing that code are the guys doing the changes who you again ASSUME that they are never gonna turn out to be a bad actor...yeah GL with that. Before there really wasn't any point attacking Linux because there just wasn't enough users to make it a juicy target...now there is crypto bugs where you can make an assload using every CPU and GPU you can get your hands on to mine coins....yeah I have a feeling you are seeing the tip of the iceberg and it won't take long before the crypto bugs come in force...again GL with that.

Re: Why so little malware?

[Zero__Kelvin]

Heartbleed is a perfect example of a problem that was only found because it was Open Source. You want to cry "look how long it took (to work)" as some argument that it didn't happen .... and again, that is stupid. The point is it was found and fixed, and that only happened because it was open source. I didn't waste my time reading the rest of the drivel you wrote. Either you are a troll or you lack the facilities to understand this simple concept.

Why not put malicious code in post-install script?

[wuyongzheng]

First, post-install script runs as root. Second, it runs during installation. If putting it in the program (e.g. acroread), the user has to run it to trigger. Most Linus package systems support post-install script. e.g. https://docs-old.fedoraproject...

Caught within 1-3 hours. Phone apps stay for month

[raymorris]

He was caught within a few hours, because all changes all public:

https://aur.archlinux.org/cgit...

Possibly bad guys would rather add trojans to iPhone and Android apps, which may stay in the store for months without detection. You can't tell what changes have been made to compiled apps you download on iPhone, Android, or Windows.

Re:Why not put malicious code in post-install scri

[Anonymous Coward]

I recommend either installing AUR packages by hand, during which you can check the Post-Install, or using a AUR Helper that allows viewing of said script. True, it takes time to verify yourself. But, a precursory glance helps screen some of the stupid stuff like pulling a script from a pastebin clone.

And yes, it takes time. That's always a tradeoff, convenience vs security.

Re:This is such a load of BS

[nnull]

More than likely a proof of concept to show some forum mods how stupid they look. It was only a matter of time someone tried to pull this off on AUR. I don't know why they don't expand on AUR to have more trusted maintainers, as there are quite a bit of programs there that have known maintainers of projects. It gets used quite often on Arch due to missing packages.

Affected Packages

[Philotomy]

According to posts on aur-general, the known affected packages are:

• acroread 9.5.5-8
• balz 1.20-3
• minergate 8.1-2

According to comments on the AUR acroread package, the script the compromised package installed (to upload system details) contained an error and wouldn't function properly. The script also installed a systemd timer, and the comments advise checking your system for:

• /usr/lib/xeactor
• /usr/lib/systemd/system/xeactor.timer
• /usr/lib/systemd/system/xeactor.service

As a side-comment, for those unfamiliar with Arch, these compromised packages are not part of the official Arch repositories. The AUR is a "user repository": a collection of user-supplied packages which require deliberate download and installation. AUR packages should [i]always[/i] be reviewed before installing them, and not installed if you don't trust the package. As the AUR documentation explains, "Warning: Carefully check all files. Carefully check the PKGBUILD and any .install file for malicious commands. PKGBUILDs are bash scripts containing functions to be executed by makepkg: these functions can contain any valid commands or Bash syntax, so it is totally possible for a PKGBUILD to contain dangerous commands through malice or ignorance on the part of the author. Since makepkg uses fakeroot (and should never be run as root), there is some level of protection but you should never count on it. If in doubt, do not build the package and seek advice on the forums or mailing list."

Re: Affected Packages

[Anonymous Coward]

The official security bulletin also advises end users to look for a highly suspect and malicious malware code called 'systemd'. If found, removal is strongly recommended and encouraged for both the sanity and security of the end user and system.

Re:Affected Packages

[AmiMoJo]

Ah, the classic wetware exploit: user too lazy to carefully examine every file before installing.

These are the infected packages

[aglider]

https://lists.archlinux.org/pi...

AUR is not secure by design, but that's fine

[damaki]

It is written basically everywhere in the AUR official documentation: do not trust AUR packages, verify everything before install! AUR packages are like Ubuntu PPAs, there is no security policy and no patch policy. But that is totally fine! It is entirely the point of AUR; anybody can contribute to it. For AUR packages security, you are on your own and you should check the sources thoroughly when you install an AUR package!

Re:AUR is not secure by design, but that's fine

[sad_]

the people who actually care are a minority, most people will just install whatever.
it's like that on windows (people just download and install anything they find on whatever shady site) or smartphones (most android problems result from installing apk's downloaded from... shady sites).
things like AUR, PPA's, containers (docker, snap, ...) etc bring this problem to linux. it's a security disaster waiting to happen.

Re: AUR is not secure by design, but that's fine

[Zero__Kelvin]

That is a ridiculous thing to say. Use of non-official packages / software is *always* a risk, and everything you are claiming is some kind of Achilles heal is actually the tools that help mitigate that risk. They work quite well and have been working well over a decade.

Re:AUR is not secure by design, but that's fine

[drinkypoo]

AUR packages are like Ubuntu PPAs, there is no security policy and no patch policy. But that is totally fine! It is entirely the point of AUR; anybody can contribute to it.

No, AUR packages are not like Ubuntu PPAs, because every deb is signed, and every PPA belongs to a specific user. You cannot get malware from another user account which has taken over a PPA simply by updating, because Ubuntu does not allow different user accounts to take over a PPA. Naturally, someone who manages to take over someone else's identity to the point that they can sign packages as that user can upload malware to their PPA, but that's true of all such schemes.

Letting users take over other users' repos is a misfeature, period. Users should have to change repos to get packages from a different user.

Re:It's a matter of trust

[aquabat]

I think the whole system is screwed up.

It could be just your keyboard driver. If you think you've been infected, maybe check that one.

Re: Moar Fake News!

[Zero__Kelvin]

I always love hearing from the idiots who say that bugs / malicious code that gets found shows that Open Source doesn't have the advantage that more bugs will be found. I wonder if y'all are really that stupid.

Re:Moar Fake News!

[Oswald McWeany]

This is IMPOSSIBLE in a Linux environment. There are MANY EYES that guarantee this CANNOT happen.

Trump 2020

It's the year of the Linux malware.

Re: It's a matter of trust

[Zero__Kelvin]

You shouldn't do it for the official / non user repos because that check gets performed automatically by the package management tool so it would be redundant.

Re: It's a matter of trust

[aglider]

So you are saying there's no way to slip into the official package system or the official software repository.
Cool.
We'd need to have that everywhere, then!

Re: It's a matter of trust

[Zero__Kelvin]

Dont be snarky about something you don't even understand. What I said is that there is a way but it involves being able to change the file(s) on the server that hold the checksums as well as the actual package(s). It is an extremely secure method, which is why you almost never see a story about an official repo being compromised.