Um user upou alguns packs contendo scripts RAT no AUR, são eles:
Isso dia 16/07/2025… Ontem, 18/07/2025, o pessoal do Arch deletou estes packs e pediram para quem instalou eles, remover-los.
O user já foi banido tanto do AUR quanto do Reddit.
RAT = Remote Access Trojan
Segue mais informações nos links abaixo:
Os AURs têm seus riscos. Obrigado por compartilhar a informação.
não uso essa distro e conheço pouquíssimo sobre AUR. Mas é um repositório público para se compilar o que a distro principal não tem? Pra mim é um risco grave de segurança pois se vc precisa do “pacote X” e tá no repositório público, a tentação é grande em instalá-lo. E aí babau.
É exatamente isso, tipo aquela “loja” de temas do KDE que qualquer um pode colocar o que quiser, até com scripts que rodam em sudo. É um grande risco de segurança, sempre evito esse tipo de coisa.
Parece que mais 4 pacotes foram detectados:
AUR e outro nível, no momento que tentam aplicar algum golpe já são pegos, já não se pode dizer o mesmo de outras bases, umas tem pacotes obscuros dentro do próprio repositório e um pacoteamento tanto quanto fácil de camuflar ameaças virtuais
Arch no seu dia mais comum.
É o mesmo que culpar uma Ferrari pelo combustível ruim.
Mas enfim🤣
E a praga continua, mais um malware agora se passando pelo Chrome.
Esse pacote instala um arquivo Python com malware que se esconde com o nome de RPC Bind, que é um serviço conhecido do linux, e cria um serviço systemd malicioso.
Upado hoje e removido hoje kkkkkkk
AUR e um paraiso mesmo, segurança com Arch não e brincadeira
De boa… Eu prefiro nem usar os AUR.
O AUR é uma solução boa, mas que o devs do Arch decidem não facilitar. Tem muito projeto que disponibiliza os PKGBUILDs de forma oficial (1password, catppuccin e etc), o Arch poderia dar um selo de verificado pra essa galera, tipo o flatpak faz, incentivaria mais gente a publicar e seria mais seguro.
Não acho que o risco de malware no AUR justifique um selo de verificado, ainda mais considerando os ataques que vimos até agora por lá.
Ambos os pacotes — e a maioria de casos de malware no AUR — duplicavam pacotes honestos muito populares – guias da internet, o sistema de votos/popularidade e a data de mudança/criação apontariam os usuários inexperientes em auditar pacotes para os originais.
E para auditar, basta saber o básico de shell script na maioria esmagadora dos casos – helpers até destacam diferenças entre as versões para facilitar esse trabalho. Essas habilidades são esperadas do público-alvo do Arch e do AUR, e, como já foi ressaltado nesse tópico, a comunidade do Arch é grande e cheia de usuários que as possuem, tanto que (até onde eu sei) todos os casos de malware no AUR são abatidos em menos de uma semana.
O outro modus operandi que eu já vi – “bichar” um pacote abandonado – teria o impacto limitado pela própria obscuridade do pacote (e, mesmo assim, esse caso também foi abatido em menos de uma semana).
Um ataque que envolva um pacote pré-existente popular sendo “bichado”, ou o primeiro pacote para um programa sob grande demanda ser malicioso (o que, até onde eu sei, nunca aconteceu) seria motivo maior de preocupação, na minha opinião.
Nesse caso específico, selos de verificado não seriam possíveis, ou exigiriam uma certa liberdade de interpretação. Um dos pacotes com “gêmeo do mal” aqui, o ttf-ms-fonts, e o caso que eu linkei acima, são abandonware, e acho que não preciso explicar o minecraft-cracked.
O Arch também é uma distribuição rolling-release, o que atrapalha a distribuição de programas cheios de dependências ou de código fechado – aqueles em que o selo de verifcado é mais importante – e torna mais ágil o suporte comunitário.
Não falei só do selo por conta de malwares.
A ideia não permitir unica e exclusivamente so quem for verificado no AUR, mas sim dar um selo caso o dev oficial queira empacotar, se não quiser, outra pessoa, sem selo, assume.
Tem vários pacotes que são mantido pelos próprios devs:
Brave (código aberto)
Catppuccin (código aberto)
yay (código aberto)
paru (código aberto)
beautyline (código aberto)
firedragon (código aberto)
1password (código fechado)
Sem fiscalizar o envio e mudança de administração de pacotes, o selo vai ser pouco eficaz.
Primeiro, pacotes sem selo (que inevitavelmente serão a maioria) ainda precisarão de todos os cuidados que são orientados hoje.
Segundo, não adiantaria muito contra ataques clássicos a repositórios que são usados principalmente pelo terminal, como typosquatting e “efeitos Mandela”. Nesse caso recente mesmo, ainda que o google-chrome do AUR estivesse verificado, um usuário que digitasse diretamente google-chrome-stable no terminal (que é o nome do pacote em outras distribuições – essa provavelmente era a intenção do mau elemento aqui) receberia imediamente o pacote bichado, a não ser que ou fosse pesquisar antes – e nesse caso a popularidade e data de modificação já ajudam – , ou o AUR impedisse pacotes com nomes parecidos, ou o AUR helper tivesse um recurso de “você quis dizer…” – os quais atrapalhariam usos legítimos como pacotes que pré-aplicam patches populares em projetos de código aberto.
Imagine o caos e a atratividade para autores de malware que seria se Flathub permitisse a qualquer um enviar variações do pacote da Steam logo após criar uma conta (que, aliás, até hoje não é verificado/oficial, mesmo o SteamOS usando Flatpak).
A equipe do GURU (“primo” do AUR no Gentoo) apenas veta manualmente a entrada e edição de pacotes (sem selo de verificação) e tem um total de zero casos de malware. É mais trabalhoso (e deve ajudar que o Gentoo é um alvo menor), mas torna o repositório realmente mais digno de confiança. Imagino que a equipe do Flathub faça o mesmo, seja com pacotes não verificados ou não.
Eu também tenho minhas dúvidas quanto à probabilidade dos itens 1 e 2.2. As habilidade necessárias para criar um pacote com qualidade (respeitar políticas e convenções da distribuição, reagir com prontidão versões de biblioteca, etc.) não são as mesmas necessárias para criar um programa com qualidade, e, como disse no post anterior, suportar o Arch é mais trabalhoso que suportar distribuições mais estáveis – e populares – como Ubuntu, RHEL, Debian, os runtimes do Flatpak, etc.