Live data from Hacker News

Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

phoronix.com

201–210 of 227 posts

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#201

Earlier quoted context omitted.

Yeah, I've prevented this locally too by never building such a platform in the first place, always the best solution! Jokes aside and just in case, you do realize ports and AUR have two very different models? Ports is more similar to the official Arch repositories, which obviously doesn't suffer from the same problem, and AFAIK, there is no BSD-equivalent of AUR. BSD is cool and useful for lots of reasons, but compar…

There is pkgsrc-wip which is similar but run by one person who does at least some checking up on new users. AUR is just gigantic in comparison; pkgsrc-wip has about as many total packages as AUR has updated in the past week. https://www.pkgsrc.org/wip/

But why check the user instead of the actual code? That's like asking people to checking the GitHub user before they install a program from GitHub, instead of the program itself! Ultimately, the PKGBUILD is the only thing that matters here, not the author or how many others reviewed it.

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#202
post #129

Has anyone from the AUR team (such as that is) published a retrospective yet? This was some impressively fast firefighting but in all honesty, it seems like some changes are needed, either in AUR policies or in the wrappers. I should be able to set a minimum package age just like I can with pnpm. Orphaned packages should not be adoptable by just anyone. Maybe there should even be a global rate limit on this as a sign…

> Someone or something should vuln-scan these packages as they're published, as a number of companies do for NPM now. That would likely have found these pretty quickly. No. It wouldn't have. That's the whole point of the miasma worm, because it changes too fast in its signatures and helper methods. The encrypted malware implant uses a changing AES-128-GCM key that's used to decrypt the payload, and that key is per-wh…

With this _actual_ attack, it would have been trivial to detect. The signature was:

1. Orphaned package adopted

2. Has post-install hook added

3. Which uses npm or bun

Yes, you're right - detecting this could have led to a more sophisticated attack. Security is always a cat and mouse game. The purpose isn't to stop every attack - it's to raise the costs for attackers and the visibility for defenders.

Any attacker who wants to attack 1000s of packages is going to necessarily leave some signatures, unless they're extremely careful. If they change one thing but not another, you can tie them both together.

Think of this like email anti-spam. It hasn't gotten rid of spam, but it has made it much more expensive to operate.

Combine this with a minimum package age to give the scanners time to run and humans time to inspect, and the ecosystem as a whole gets much more secure.

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#203
post #129

Has anyone from the AUR team (such as that is) published a retrospective yet? This was some impressively fast firefighting but in all honesty, it seems like some changes are needed, either in AUR policies or in the wrappers. I should be able to set a minimum package age just like I can with pnpm. Orphaned packages should not be adoptable by just anyone. Maybe there should even be a global rate limit on this as a sign…

There is no official tool to download aur repos, so that’s up to whatever you do.

I've used three in my career as an Arch user:

yaourt

yay

paru

https://github.com/Morganamilo/paru/issues/1563

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#204

Earlier quoted context omitted.

Better would be to namespace AUR packages. That way, ownership is not lost and we don't need orphaning at all.

Are you suggesting like .packaged-by.joe-Schmoe ? And then if Joe Schmoe abandons it, people should instead switch to .packaged-by.Abe-Lincoln etc?

I mean we can talk about the actual naming scheme but essentially yes.

It is also an explicit signal of someone different taking over the ownership.

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#205

I’m not on Arch Linux, but I am on NodeJS a lot, which frequently suffers from similar types of attacks. Who is doing package management right these days? Who is doing it securely?

Min Release Age of 7-30 days covers the majority of potential issues with 0 effort. All major Node package managers should support it by now. Prom was the best IIRC, yarn second, but even npm is catching up

We’re using an internal package repository that acts as a gateway to the public package repositories, except it can have custom rules such as “min release age 30 days”, and can also give logs about which projects have actually downloaded a specific version.

It’s so much overhead and auditing to enforce compliance across the thousands of node microservices though.

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#206
post #32

I’m not on Arch Linux, but I am on NodeJS a lot, which frequently suffers from similar types of attacks. Who is doing package management right these days? Who is doing it securely?

The AUR is user supported and thus malware sneaks into packages all the time, although admittedly not to this scale. Still, it's pointedly not secure and has always had "here be dragons" signs plastered all around it.

That’s not so much an example of who is using best practices, as it is an example of who is using worst practices.

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#207

I’m not on Arch Linux, but I am on NodeJS a lot, which frequently suffers from similar types of attacks. Who is doing package management right these days? Who is doing it securely?

Linux distributions are. They all have maintainers who vet packages and take responsibility for them. Arch Linux does too. The inherent untrustworthiness of the AUR was always made explicit by the Arch Wiki and the culture surrounding it, unlike programming language package managers like npm and pip.

Having trusted community members vet packages is a good system, but how much does it really scale?

1. The whole point of the AUR is that the demand for packages outstrips the volunteer effort to provide secure packages.

2. There are about a dozen major package systems for Linux, with a lot of duplicated effort in packaging the same software for slightly different systems in slightly different formats.

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#208

I’m not on Arch Linux, but I am on NodeJS a lot, which frequently suffers from similar types of attacks. Who is doing package management right these days? Who is doing it securely?

I think something about the node ecosystem makes it particularly vulnerable. Maybe it's the insane "dry" ethos. Or something else. Nothing I have ever used has a comparable dependency tree nightmare.

I think most ecosystems have more batteries included than node.

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#209

I’m not on Arch Linux, but I am on NodeJS a lot, which frequently suffers from similar types of attacks. Who is doing package management right these days? Who is doing it securely?

Running external code will always be a risk. Even if it is not intended to be malicious it could still have issues that compromise security. Read the source. If you don't have the time then you shouldn't run the software.

By “external code” do you mean code that is not written by yourself or the organization you are working in?

The Linux Kernel has 40 million lines of code, I don’t have the time to read that so I guess I better not use it.

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#210
post #38

Earlier quoted context omitted.

I think the existence of the AUR puts less pressure on the official repository to have all popular software.

I think it's also a bit of a testing ground for the main repos as well. I maintained the `ruby-build` AUR package for a couple of years after the previous maintainer wanted to step down, but they eventually added it to the main repos and now it's maintained by one of the official people. (I don't recall ever having to do more than paste in the new release tag into the PKGBUILD each time and then generate the new .SRC…

I’ve seen automation scripts for this process of updating packages.

Makes sense that the most popular AUR packages will be candidates for the main repo.

Post reply on HN