• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Huge Malware Attack on AUR

Bankie

2[H]4U
2FA
Joined
Jul 27, 2004
Messages
2,787
Last edited:
I had to Google that one...

Oop... Must be that one:

aur.png


And that actually reminded me that I DID grab something from there once, but it was only some source code patches that allow old Nvidia 470.xx drivers to compile against more modern kernels, not any packages installed directly.

I guess it is a reminder not to trust random user created stuff online.
 
In this case it was poor repository security combined with people just installing whatever without checking to be sure it was safe first.

The AUR allows anyone with an account to take over orphaned packages in the Arch User Repository to maintain themselves. Well, that also means than anyone can take over a package and make it do whatever they want on your computer. They used that to install a program, steal credentials, and take over other maintained packages as well. And who knows what else.

The AUR is unsafe by default. It is expected that you should inspect the pkgbuild script and source before building and installing packages from the AUR. But of course nobody does that (myself included, many times). It was a matter of time, this is why we can't have nice things, and all that.
 
So Linux is more secure because it's open source??? :rolleyes:

Nothing is secure if you carelessly install software from repositories maintained by the general public.

One of the many things that has made Linux more secure in the past is simply because of the tight control over the source of the software. If you are doing things right you shouldn't be downloading and installing software on your own, but rather getting it directly from the one central repository for your distribution, who h is vetted by and controlled by the team that develops the distribution.

As soon as you add some random PPA or other community source you have opened a wide open door for malware to be installed.

Windows used to be really bad security wise, but ever since Vista introduced UAC Windows itself has actually been quite decent. Most exploits in Windows comes from third party software. Adobe has been a huge attack vector over the years. Linux distributions mostly avoid this problem simply by keeping all software in house.

Though with stupid binary blob distributions like Snaps, Flatpaks and Appimage Linux is becoming more and more vulnerable to 3rd party crap.
 
Nothing is secure if you carelessly install software from repositories maintained by the general public.

One of the many things that has made Linux more secure in the past is simply because of the tight control over the source of the software. If you are doing things right you shouldn't be downloading and installing software on your own, but rather getting it directly from the one central repository for your distribution, who h is vetted by and controlled by the team that develops the distribution.

As soon as you add some random PPA or other community source you have opened a wide open door for malware to be installed.

Windows used to be really bad security wise, but ever since Vista introduced UAC Windows itself has actually been quite decent. Most exploits in Windows comes from third party software. Adobe has been a huge attack vector over the years. Linux distributions mostly avoid this problem simply by keeping all software in house.

Though with stupid binary blob distributions like Snaps, Flatpaks and Appimage Linux is becoming more and more vulnerable to 3rd party crap.
Also because it was overwhelming nerds using Linux. As Linux becomes more mainstream you get more people that don't know what they are doing and it becomes an easier, more worthwhile target.
 
Installing software in general is inherently dangerous, it's really that simple. Even if you compile from source, are you inspecting that makefile? I bet your not. Even if you were on top of things and you did inspect that makefile and understood every aspect of the code contained within, are you inspecting files and targets used by the makefile? Once again, I bet you're not.

In such an example, the vulnerability isn't related to the system, the vulnerability is us and the blind trust we put in the system.
 
It's becoming less secure every day. It was more "secure" before because Linux wasn't a big target. There seems to be new Linux vulnerabilities all the time now. Some are very basic python scripts that grant root access.
So "security through obscurity" doesn't work any longer.
 
So "security through obscurity" doesn't work any longer.
This is one of the dumbest comments and has been one of the dumbest comments for years. Linux is the most used OS in the world and has been for a long time. It is the literal backbone of the internet and probably most businesses. There is nothing obscure about Linux.
 
This is one of the dumbest comments and has been one of the dumbest comments for years. Linux is the most used OS in the world and has been for a long time. It is the literal backbone of the internet and probably most businesses. There is nothing obscure about Linux.
I believe people who talk about Linux on here are mostly referring to desktop environments. Security has always been better (thinking servers, etc) when only people running Linux are system engineers and developers keeping that Internet alive. So while not obscure from the Internet, it's obscure from less skilled people who can make mistakes. As Linux becomes more end user facing you will start seeing more attacks geared specifically towards those people. Privilege escalation and other Linux security measure will only go so far to protect them.

So I don't disagree with you on principle I do think it's more complicated than this.
 
I believe people who talk about Linux on here are mostly referring to desktop environments. Security has always been better (thinking servers, etc) when only people running Linux are system engineers and developers keeping that Internet alive. So while not obscure from the Internet, it's obscure from less skilled people who can make mistakes.
Not even so much that the SAs running servers are more skilled (there are some DUMB SAs out there and many of them hate patching) it is just less surface and less interaction. With many servers, people rarely log in and if they do it is to do basic shit like run patches. So the only attack surface is the server applications themselves. Whatever is surfaced and you can poke at. If the server is an internal server, not public facing, then it is even harder since you already need to be in the corporate network.

However for a desktop computer there's a much larger attack surface since there's a user on it all the time. Any of their apps that connect to the Internet are a potential point of attack, and of course just getting them to download something from the web or e-mail and run it is a huge attack surface.

That's why in orgs with highly mature security processes you do sever administration though dedicated, locked down, endpoints because a way one can get compromised is for an SA to get their desktop owned, then log in to a server, and then the attacker has server credentials.

This is one of the dumbest comments and has been one of the dumbest comments for years. Linux is the most used OS in the world and has been for a long time. It is the literal backbone of the internet and probably most businesses. There is nothing obscure about Linux.
Yet plenty of Linux users still act like it keeps them secure (Mac users too). You hear from people that you don't need a virus scanner because "Linux doesn't have viruses" which is not only provably false, but if it was true the only reason would be because people weren't writing them for it (security through obscurity).

The AUR is unsafe by default. It is expected that you should inspect the pkgbuild script and source before building and installing packages from the AUR. But of course nobody does that (myself included, many times). It was a matter of time, this is why we can't have nice things, and all that.
That's extremely unrealistic though. The idea that most users have the ability to inspect source is just not realistic and even those that do aren't going to spend the time. Telling end users "Just do security better!" is always a losing proposition. It's why we need to have things like anti-malware scanners (blacklisting basically) unless we want a completely locked down environment where you can install only trusted software (whitelisting). Throwing security on the end user and demanding they just know how to security right has always, always, failed in the past and thus there's pretty good reason to believe it isn't ever going to be successful.

It makes nerds feel nice and smug and superior to say "You did the security wrong!" to people that get hit (until it is the nerd that gets hit, seen that more than once) but it isn't useful or a realistic path forward.
 
Not even so much that the SAs running servers are more skilled (there are some DUMB SAs out there and many of them hate patching) it is just less surface and less interaction. With many servers, people rarely log in and if they do it is to do basic shit like run patches. So the only attack surface is the server applications themselves. Whatever is surfaced and you can poke at. If the server is an internal server, not public facing, then it is even harder since you already need to be in the corporate network.

However for a desktop computer there's a much larger attack surface since there's a user on it all the time. Any of their apps that connect to the Internet are a potential point of attack, and of course just getting them to download something from the web or e-mail and run it is a huge attack surface.

That's why in orgs with highly mature security processes you do sever administration though dedicated, locked down, endpoints because a way one can get compromised is for an SA to get their desktop owned, then log in to a server, and then the attacker has server credentials.


Yet plenty of Linux users still act like it keeps them secure (Mac users too). You hear from people that you don't need a virus scanner because "Linux doesn't have viruses" which is not only provably false, but if it was true the only reason would be because people weren't writing them for it (security through obscurity).


That's extremely unrealistic though. The idea that most users have the ability to inspect source is just not realistic and even those that do aren't going to spend the time. Telling end users "Just do security better!" is always a losing proposition. It's why we need to have things like anti-malware scanners (blacklisting basically) unless we want a completely locked down environment where you can install only trusted software (whitelisting). Throwing security on the end user and demanding they just know how to security right has always, always, failed in the past and thus there's pretty good reason to believe it isn't ever going to be successful.

It makes nerds feel nice and smug and superior to say "You did the security wrong!" to people that get hit (until it is the nerd that gets hit, seen that more than once) but it isn't useful or a realistic path forward.
Nobody said you have to do it, they just said if you don't then you are not safe, you shouldn't expect to be safe, rather, you are probably fucked. I think that's fair and reasonable.
 
Nobody said you have to do it, they just said if you don't then you are not safe, you shouldn't expect to be safe, rather, you are probably fucked. I think that's fair and reasonable.
Fair... but then that isn't a very secure setup.
 
I DON'T think it's safe, I don't trust it, and you shouldn't either. The cool thing is we don't have to use it.
 
The unfortunate thing is it was convenient, and now it'll probably be shut down (least temporarily).
I don't think it was really meant to be convenient, but it was.
 
I guess the bigger question is if it is such a huge insecurity, why is it something that is not only available but advertised on the Arch homepage?
AUR is basically what makes Arch Arch, besides pacman. Packages are submitted to AUR, voted on, and if a maintainer shows interest, it's picked up and added to an official repo (community or main). Without AUR, it's just another distro with packages mostly decided by the few people behind the scenes.
 
This is one of the dumbest comments and has been one of the dumbest comments for years. Linux is the most used OS in the world and has been for a long time. It is the literal backbone of the internet and probably most businesses. There is nothing obscure about Linux.
I was referring to the time when Linux was not used as much. Same was true of MacOS
 
Luckily, I use pretty much exclusively Linux Mint on all of my Linux PCs. It has worked great for AI dabbling so far, even with Nvidia hardware. The exception is that long-running cuda tasks tend to crash the desktop UI if your desktop is also running on the Nvidia card, but switching over to using my Intel IGPU has worked beautifully and frees up all of my 5090's VRAM to do cuda things while keeping the interests clearly separated.
 
It's only orphaned packaged that have been compromised. If you use an AUR helper like paru, not only does paru tell you the package has been orphaned (and is therefore not worthy of installation), it also highlights the changes in PKGBUILD scripts for easier examination.
 
The orphaned pkgs were un-orphaned by a malicious user, modified, and used to steal credentials of other users and take over more orphaned pkgs. The compromized pkgs are NOT orphaned anymore, so you won't get that warning when attempting to install the first time, or if you are updating after they were compromized.

Some would probably ignore that warning anyway, since being orphaned just means the pkgbuild may not work anymore, and fixing it if it doesn't is often pretty simple.
 
Some would probably ignore that warning anyway, since being orphaned just means the pkgbuild may not work anymore, and fixing it if it doesn't is often pretty simple.
In terms of the average user that isn't a Linux coder, a package being listed as orphaned definitely has people looking for the package elsewhere under either the official Arch repo's or the CachyOS repo's (in terms of CachyOS) - and the best thing about an AUR helper, is it'll actually tell you if a maintained version of the software is available under either official repository. I always avoid packages listed as orphaned under paru, therefore luckily I seem too have avoided installing any of the infected packages in the first place. Furthermore, the changes to the packages were as low key and minimal as possible:

  • The update didn't change any source or checksum.
  • The diff changed the email of the previous maintainers but not the names. It should only have added their own name and email to preserve the history.
  • The diff added a nonsensical dependency and a post install script that will be run by your user outside of the build chroot.
The only reason someone picked up on the hack was due to the fact they thought it was suspicious that a vast number of AUR packages were suddenly updated by the same user at the same time.
 
Last edited:
Looks like a second plane has hit the AUR and there's been an another wave today

I guess this is why we can't have nice things. I don't think AUR is dead by any means, but it's probably time to do a little more than say "be careful, it's the wild west."

Like a probationary period after certain actions. Any time something is orphaned/adopted or ownership changes, it needs to be explicitly flagged as being extra high risk.

Maintainers need MFA. Rate limits on adoptions. Won't stop any dedicated attacker but it's still additional friction for people coming out of thin air and touching packages.

Super obvious diffs for PKGBUILD and .install changes. Sandboxing would be interesting where these packages run in a sandbox and dumps files accessed, network requests, and commands executed.
 
Back
Top