AUR Parte 2: O Caos Continua; Agora são 1.500 Pacotes Afetados
A investigação sobre o ataque ao AUR escalou de centenas para mais de 1.500 pacotes afetados. E, para melhorar a piada, eu também tinha um deles instalado.
Eu publiquei um post falando sobre mais de 400 pacotes do AUR comprometidos com payloads associados a infostealer e rootkit-like malware.
Pois é.
Aparentemente, 400 era só o trailer.
A atualização mais recente da investigação aponta para algo na casa de 1.500 pacotes afetados, espalhados em ondas diferentes da campanha que a Sonatype chamou de Atomic Arch. A lista pública discutida no aur-general também cresceu bastante, e os próprios mantenedores do Arch chegaram a publicar uma nota dizendo que removeram os commits maliciosos conhecidos naquele momento, junto de uma lista com muitos dos pacotes afetados.
Repare na palavra importante: conhecidos.
Esse detalhe muda o tom da conversa. O caso deixou de ser “alguns pacotes obscuros foram comprometidos” e virou “o modelo de confiança do AUR recebeu um soco bem dado na cara”.
Não era só atomic-lockfile
No primeiro momento, a campanha parecia girar principalmente em torno de PKGBUILDs alterados para puxar uma dependência npm chamada atomic-lockfile.
Isso já era ruim o suficiente. O pacote malicioso trazia um payload nativo Linux com indícios de coleta de credenciais, tentativa de ocultação e potencial exfiltração de dados. A análise também apontou referências a eBPF e APIs de libbpf, o tipo de coisa que faz qualquer usuário Linux parar de rir e começar a olhar para o backup com carinho.
Só que depois apareceram outras ondas.
Além de atomic-lockfile, os relatos passaram a citar também js-digest, lockfile-js e até caminhos de instalação usando Bun em vez de npm. Ou seja: não era um único pacote ruim jogado por acidente em alguns PKGBUILDs. Era uma campanha se adaptando.
A tese do post anterior continua de pé, mas agora com mais peso: o problema não é “um pacote malicioso”. O problema é a facilidade com que confiança herdada vira vetor de ataque.
O AUR não foi invadido como um repositório oficial
Esse ponto continua importante.
O AUR não é o repositório oficial do Arch. Ele é um repositório comunitário de receitas de build. Um pacote AUR normalmente é um repositório Git com um PKGBUILD, arquivos auxiliares e, às vezes, scripts de instalação.
E PKGBUILD é shell script.
Shell script executa comandos.
A beleza do AUR é justamente essa transparência: está tudo ali para você ler. A tragédia é que quase ninguém lê.
O ataque explorou uma parte bem sensível desse modelo: pacotes órfãos ou abandonados. Um pacote que já tinha nome, histórico, votos, usuários e aparência de legitimidade podia ser adotado por outro mantenedor. A partir daí, bastava alterar a receita de build para puxar uma dependência maliciosa durante o fluxo normal de instalação.
Não precisava convencer o usuário a instalar um pacote chamado totally-not-a-stealer-bin.
Bastava alterar algo que ele já confiava.
E agora vem a parte ridícula: eu também estava na lista
Depois de escrever sobre o caso, fui fazer a checagem na minha própria máquina.
Adivinha.
Eu tinha astah-uml instalado.
E astah-uml aparece na lista de pacotes afetados discutida na thread do aur-general.
A parte tragicômica é essa: eu escrevi um texto inteiro sobre não tratar o AUR como loja de aplicativo e, no fim, tinha um pacote da lista instalado no meu próprio sistema. Tecnologia é maravilhosa porque ela sempre encontra um jeito de te humilhar com logs.
Tecnicamente, eu não vou cravar aqui que minha máquina foi “comprovadamente infectada” sem uma análise forense completa. O que dá para afirmar é pior para o ego e melhor para a precisão: eu estava exposto.
E quando você está exposto a um possível infostealer com comportamento de ocultação, a resposta responsável não é “desinstalei, vida que segue”.
Eu removi o pacote. Rotacionei chaves SSH. Revoguei tokens. Revisei credenciais. Tratei a máquina como suspeita.
Porque pacote removido não desfaz chave vazada.
O que eu corrigiria no texto anterior
A primeira correção é trocar “mais de 400 pacotes” por “mais de 1.500 pacotes afetados”, deixando claro que o número ainda pode variar conforme a auditoria avança.
A segunda é tomar cuidado com a palavra “infectado”. Pacotes podem estar afetados no AUR sem que toda máquina que tem aquele nome instalado tenha necessariamente executado o payload. O risco real depende de janela de instalação, atualização, execução do script malicioso e do que de fato rodou no ambiente local.
A terceira é não reduzir tudo a atomic-lockfile. Esse foi o primeiro nome forte da história, mas a campanha parece ter usado mais de um pacote malicioso e mais de um caminho de instalação.
A quarta é reforçar a recomendação mais chata e mais correta: se você instalou ou atualizou um pacote afetado durante a janela do ataque, trate como incidente. No mínimo, revise logs, remova o pacote, rotacione credenciais sensíveis e olhe com carinho para tudo que estava salvo no seu $HOME.
O ouro de um infostealer normalmente não está em virar root.
Está nas suas chaves SSH, tokens de GitHub, credenciais de cloud, .env esquecidos, cookies, CLIs logadas e arquivos de configuração que você jurou que ia limpar “qualquer dia”.
AUR helper não é airbag
Eu continuo gostando de helpers como yay e paru.
Mas helper não é auditor. Ele mostra diff, mas não lê por você. Ele pergunta se quer revisar, mas não obriga você a entender. Ele automatiza build, mas não transforma script de desconhecido em software confiável.
O problema não é usar AUR. O problema é usar AUR como se fosse Steam.
Clicar, instalar, atualizar tudo em lote, ignorar diff, aceitar mudança de mantenedor, pular comentário, confiar em pacote órfão, fazer --noconfirm e depois agir surpreso quando a cadeia de confiança cobra a conta.
O AUR continua sendo uma das melhores partes do Arch.
Também continua sendo uma das partes que mais exigem maturidade do usuário.
Conclusão: o caos continua, mas o aviso também
O incidente do AUR não prova que Arch é inseguro por natureza. Essa leitura é preguiçosa.
Ele prova algo mais desconfortável: transparência não protege quem não olha. Flexibilidade não protege quem terceiriza julgamento. Comunidade não substitui modelo de ameaça. E conveniência, quando passa do ponto, vira anestesia.
No meu caso, a lição deixou de ser teórica quando encontrei astah-uml na minha própria máquina.
Nada como um ataque de supply chain para transformar opinião técnica em tarefa de sábado.
O AUR não acabou. O Arch não morreu. Linux não virou Windows com vírus, por favor, menos.
Mas a frase do post anterior continua valendo, agora com juros compostos:
PKGBUILD é código. Código executa. Código de terceiros exige revisão.
E contrato de confiança, em infraestrutura, sempre cobra juros.