Versões maliciosas do Nx e de alguns plugins compatíveis foram distribuídas

• Versões maliciosas do pacote Nx e de plugins foram publicadas no npm, escaneando o sistema de arquivos, coletando credenciais e depois enviando tudo para um repositório da conta Github do usuário
• Para verificar se houve impacto, é preciso confirmar se o repositório s1ngularity-repository foi criado na conta do Github
• Em caso de infecção, é obrigatório trocar tokens e senhas, excluir o repositório malicioso e verificar arquivos de configuração do shell
• As versões maliciosas afetam o sistema por meio de um script postinstall; o risco de execução involuntária aumenta especialmente ao usar o plugin VSCode Nx Console
• A equipe do Nx aplicou medidas adicionais de segurança e prevenção de recorrência, e as versões relacionadas foram removidas do npm

---

Visão geral e resumo

• Este aviso de segurança trata de um grave ataque à cadeia de suprimentos envolvendo o pacote Nx e alguns plugins relacionados, com código malicioso distribuído via npm
• Essas versões maliciosas escaneavam o sistema de arquivos do usuário para coletar credenciais, caminhos e outras informações, enviando os dados para um repositório do Github chamado s1ngularity-repository
• O script malicioso de postinstall também modificava os arquivos de configuração do shell do usuário (.zshrc, .bashrc) para adicionar comandos de desligamento do sistema
• O documento detalha o vetor de ataque, a progressão do incidente, as versões afetadas, as ações imediatas que os usuários devem tomar e as medidas de prevenção de recorrência

Como agir com urgência

O que todos devem verificar

1. Verifique na lista de repositórios da sua conta Github se foi criado o s1ngularity-repository
2. Baixe os arquivos incluídos nesse repositório e mantenha-os arquivados como registro
3. Exclua o repositório no Github
4. Envie um e-mail para [e-mail] para receber orientações sobre como decodificar as informações vazadas
5. Troque imediatamente todas as credenciais e tokens de todas as contas

Como trocar o token do Github

• Acesse https://github.com/settings/connections/…
• Revogue o acesso do app conectado para invalidar o token existente
• Se você usa o gh CLI, autentique-se novamente para gerar um novo token
• Se isso não for feito, há risco de abuso do token antigo

Interromper o uso das versões maliciosas do Nx e limpar o ambiente

• Verifique se a versão atualmente em uso do Nx é uma das versões maliciosas com o comando npm ls nx
• Se for uma versão infectada, atualize com npm uninstall nx && npm install nx@latest
• Limpe o cache com npm cache clean --force

Usuários já infectados

• Troque os tokens do npm e do Github
• Redefina todas as senhas e credenciais do Github e de serviços relacionados
• Verifique os arquivos .zshrc e .bashrc para identificar comandos desconhecidos inseridos e remova-os

Para administradores de repositórios internos de pacotes

• É necessário remover imediatamente as versões maliciosas do proxy no registro interno da empresa para bloquear propagação adicional

Versões afetadas

Pacote Nx

• 21.5.0, 20.9.0, 20.10.0, 21.6.0, 20.11.0, 21.7.0, 21.8.0, 20.12.0
• Removidas do npm até 10:44 PM EDT

@nx/devkit, @nx/js, @nx/workspace, @nx/node, @nx/eslint, @nx/key, @nx/enterprise-cloud

• Removidos do npm até 10:44 PM e 6:20 AM EDT

Detalhes do vetor de ataque

Causa do workflow vulnerável

• Uma vulnerabilidade que permitia execução arbitrária de código foi introduzida no workflow do Github Actions
• Ao inserir um código bash específico no título de um PR, surgia uma vulnerabilidade em que comandos do sistema eram executados no workflow (Bash Injection)
• O problema foi explorado por meio do gatilho pull_request_target, que concedia privilégios elevados, incluindo GITHUB_TOKEN
• Até ser removido, o workflow vulnerável permaneceu em branches antigas, não apenas na main, permitindo que o invasor executasse o workflow com PRs maliciosos e roubasse segredos

Processo de roubo do token npm

• O workflow vulnerável foi usado para executar o publish.yml
• O publish.yml armazenava o token do npm no Github Secrets, e nesse processo o token era enviado para um webhook externo
• Por fim, o invasor usou esse token para publicar no npm versões maliciosas do Nx e dos pacotes compatíveis

Comportamento do pacote malicioso

Coleta de informações com credenciais e publicação em repositório do Github

• Quando o script postinstall do pacote Nx infectado era executado, ele coletava localizações de vários arquivos de texto e informações de credenciais
• Os dados eram codificados em base64 e enviados para um repositório do Github chamado s1ngularity-repository
• Mesmo que o repositório real já tenha sido excluído, é preciso considerar a possibilidade de vazamento, já que anteriormente ele esteve público

Alteração do perfil do shell (.zshrc, .bashrc)

• O postinstall inseria o comando sudo shutdown -h 0, podendo induzir o desligamento do sistema ao abrir o terminal e expor senhas

Vários cenários em que o postinstall pode ser executado

• Além da execução explícita de npm install/yarn/pnpm install, ele também pode rodar em várias situações, como dependências transitivas, extensões de editor e execução de scripts

• Em especial, a extensão Nx Console para VSCode (versões 18.6.30 ~ 18.65.1) podia instalar automaticamente nx@latest ao iniciar o editor, acionando o postinstall

• Em essência, é preciso ter em mente que instalações de módulos NPM podem acontecer em vários pontos mesmo sem intenção direta

• A partir do Nx Console 18.66.0, o processo de instalar o latest nx foi removido

Linha do tempo do ataque e da resposta

21 de agosto

• 4:31 PM: PR com a vulnerabilidade de injeção Bash foi mesclado
• 10:48 PM: Uma publicação apontando a vulnerabilidade foi postada no X (antigo Twitter)

22 de agosto

• Tarde: investigação interna e rollback do workflow vulnerável (incompleto)
• Com a adoção do CodeQL, passou a haver detecção de vulnerabilidades semelhantes em PRs futuros

24 de agosto

• Foi feito um commit no fork do invasor com indícios de vazamento do token npm
• Um PR malicioso foi criado e depois removido, e o publish.yml foi executado por esse PR

26 a 27 de agosto (distribuição das versões maliciosas e resposta)

• Várias versões maliciosas do Nx e de plugins foram publicadas no npm em sequência
• Houve relatos do problema para as comunidades Github/NPM
• 10:44 PM: o NPM removeu todas as versões afetadas e tomou outras medidas
• 11:57 PM: todos os tokens de publicação de pacotes relacionados ao Nx foram invalidados
• 27 de agosto: correção no Nx Console, ativação de 2FA, migração para Trusted Publisher e outras medidas adicionais

Medidas preventivas e resposta posterior

• 2FA passou a ser obrigatório para todos os maintainers da organização nrwl
• Foi adotado o mecanismo de Trusted Publisher. Publicações baseadas em token npm foram proibidas
• Daqui em diante, os pacotes serão publicados somente após verificação com 2FA e confiança
• Detecção adicional de risco, aprovação de PR e proteção de branch serão aplicadas em etapas

Lições e próximos passos

• O incidente reforça a importância global da segurança da cadeia de suprimentos, dos pipelines de CI/CD e da redução de privilégios em workflows
• Após nova avaliação interna, a equipe pretende compartilhar com a comunidade o que aprendeu

Contato

• Contato disponível via [e-mail]

Referências e apêndice

• Principais issues do Github, linha do tempo e posts relacionados
• É fornecido um exemplo do script telemetry.js contido no pacote infectado
• Esse script coleta, com o objetivo de criar um inventário, os caminhos de arquivos de texto importantes no sistema de arquivos

Resumo da conclusão

• É importante aplicar as atualizações e correções mais recentes do Nx e dos plugins relacionados
• Recomenda-se a troca imediata das principais credenciais de autenticação, como npm e Github
• O caso mostra como falhas em segurança da cadeia de suprimentos e no gerenciamento de permissões de workflow podem levar a um grande incidente

[GN⁺]

Comentários do Hacker News

• Quero lembrar periodicamente as pessoas de desativarem os scripts do npm install

  • Um exemplo é usar o seguinte comando:

      npm config set ignore-scripts true [--global]
    

  • Essa configuração pode ser aplicada facilmente por projeto ou globalmente

  • Hoje em dia, é raro haver pacotes legítimos que não funcionem sem scripts, então na maioria dos casos isso não causa problema

  • Para pacotes que realmente precisem disso para funcionar, dá para contornar criando um script de instalação separado e executando-o manualmente naquela pasta

  • Não é uma solução universal contra ataques à cadeia de suprimentos, mas na prática bloqueou com eficácia muitos ataques via npm

  • Para mais detalhes, veja a documentação oficial do npm config

  • Eu também uso o bubblewrap para executar npm, pnpm, yarn e todas as sessões que eles iniciam isoladas do sistema

    • Meu código-fonte existe apenas em ~/code, e eu salvo o script bash abaixo como npm no início do PATH
    • Os outros gerenciadores de pacotes também são ligados via symlink/hardlink:

      #!/usr/bin/bash
      bin=$(basename "$0")
      exec bwrap \
        --bind ~/.cache/nodejs ~/.cache \
        --bind ~/code ~/code \
        --dev /dev \
        --die-with-parent \
        --disable-userns \
        --new-session \
        --proc /proc \
        --ro-bind /etc/ca-certificates /etc/ca-certificates \
        --ro-bind /etc/resolv.conf /etc/resolv.conf \
        --ro-bind /etc/ssl /etc/ssl \
        --ro-bind /usr /usr \
        --setenv PATH /usr/bin \
        --share-net \
        --symlink /tmp /var/tmp \
        --symlink /usr/bin /bin \
        --symlink /usr/bin /sbin \
        --symlink /usr/lib /lib \
        --symlink /usr/lib /lib64 \
        --tmpfs /tmp \
        --unshare-all \
        --unshare-user \
        "/usr/bin/$bin" "$@"
      

    • Assim, o gerenciador de pacotes só tem acesso a ~/code e acesso somente leitura às bibliotecas do sistema
    • O bubblewrap é estável e é usado por ferramentas como Steam e flatpak

  • Usar pnpm também é uma opção. Nas versões mais recentes, ele ignora por padrão todos os scripts de ciclo de vida, e só executa os que forem colocados individualmente em uma whitelist

  • Sempre que ouço esse conselho, fico com uma dúvida: na prática, não existe desenvolvedor que leia todas as dezenas ou centenas de milhares de linhas de código instaladas pelo npm

    • O fluxo de trabalho da maioria dos desenvolvedores costuma ser este:
      1. git clone
      2. npm install (aqui existe o risco de instalar um pacote malicioso; ignorar scripts de post-install pode barrar isso temporariamente)
      3. npm run (aqui o pacote malicioso é executado e a infecção acontece)
    • Para esse conselho realmente ajudar, seria preciso monitorar/auditar todo o node_modules entre as etapas 2 e 3, e ninguém faz isso

  • Eu executo todas as ferramentas baseadas em npm dentro de um contêiner Docker, sem acesso a nada além do diretório atual

    • Isso reduz drasticamente a superfície de ataque
    • O método está descrito neste blog

  • Fico me perguntando por que esse tipo de conselho não se aplica da mesma forma a setup.py (Python) ou build.rs (Rust)

    • Talvez porque o npm muitas vezes é usado até para distribuição de software (por exemplo, distribuir programas separados), enquanto os gerenciadores de pacotes de outras linguagens são usados só para gerenciar bibliotecas
    • Há uma discussão relacionada aqui

• Precisamos de uma cultura de pensar duas vezes antes de adicionar uma nova dependência

  • Este ano houve muitos ataques à cadeia de suprimentos

  • Esta semana eu queria adicionar ao meu projeto Go uma barra de progresso com 8 contadores estatísticos

  • Procurei bibliotecas e encontrei uma com mais de 3.000 linhas de código, então pedi a um LLM para gerar um código de UI simples e resolvi em menos de 150 linhas

  • Funciona exatamente como eu queria, sem dependências, e é tão simples que qualquer um consegue ler e melhorar

  • Os recursos são limpar a saída do terminal, redesenhar a cada segundo e suporte a thread safety

  • Implementar e revisar isso levou só 25 minutos

  • Se você não precisa de estatísticas complexas, dá para implementar uma barra de progresso até com umas 30 linhas de código

  • Daqui para frente, quando eu pensar em adicionar dependências, acho que para mim faz mais sentido simplesmente fazer eu mesmo

  • Não tenho recursos para monitorar todas as atualizações de todos os pacotes

  • Concordo com isso, e me lembro de como fiquei desconfortável no começo da popularização dos “gerenciadores de pacotes por linguagem”

    • Eu trabalhava com programação de sistemas e observava pip, npm etc. de longe
    • Quando fui para projetos em Rust e vi que com uma única linha no Cargo eu estava puxando da internet dezenas de dependências não verificadas, pensei que aquilo era perigoso
    • E acabou mesmo acontecendo. Não acho que seja uma boa direção. (Mas também não espero que a gente volte atrás, já que segurança de computadores basicamente não existe...)

  • Acho que a abordagem do cargo vet é o caminho: introdução ao cargo vet

    • Claro, o overhead é inevitavelmente alto se quisermos um sistema desses em todos os ecossistemas de linguagem
    • A internet do começo e o email também já tiveram tempos melhores, mas acabaram sendo arruinados por spam e comercialização
    • Agora até a cadeia de dependências está sofrendo esse tipo de dano
    • É por isso que não conseguimos manter por muito tempo ambientes bons assim

  • A diferença entre implementar você mesmo e usar uma biblioteca é óbvia

    • Bibliotecas são, por natureza, genéricas e precisam ser flexíveis e configuráveis para vários ambientes, então o código inevitavelmente fica maior

  • Eu realmente odeio essas bibliotecas de barra de progresso, especialmente as que quebram o shell do Emacs (expo, eas etc.)

    • Não entendo por que não imprimem simplesmente algo como ..10%..20%..30% ou Uploading…
    • Acho que códigos de controle de terminal deveriam ser usados só para TUI ou interfaces interativas

  • Nossa equipe opera um grande monorepo e várias bibliotecas em torno do NX dentro de uma grande seguradora

    • Gerenciamos mais de 10 apps independentes e mais de 25 bibliotecas em um único monorepo, com CI/CD fortemente acoplado
    • Também tentamos lerna, rushjs, yarn workspaces etc., mas nada funcionou tão bem quanto o NX (lerna acabou sendo adquirido pelo próprio NX, e rushjs já não parece mantido)
    • Queria que alguém sugerisse uma forma ou alternativa para realmente lidar com a complexidade de monorepos frontend
    • Como muita gente passou a se interessar por alternativas depois deste incidente de segurança, estou esperando opiniões variadas

• Em vez de culpar Nx, Anthropic ou a plataforma, precisamos repensar a causa real

  • A causa prática deste ataque foi o fato de um “token” roubado (uma string que autoriza operações no gerenciador de pacotes) poder ser usado para enviar pacotes maliciosos
  • Mas isso foi só o meio de entrega; as causas fundamentais que permitiram o sucesso foram estas:
    1. O repositório do gerenciador de pacotes não exige assinatura dos artefatos, então não era possível verificar que aquilo foi criado por um desenvolvedor autorizado
    2. Assinatura de código também não era obrigatória
    3. (Suposição) não havia heurísticas para bloquear uploads suspeitos, como detecção de comportamento anômalo, novo IP, mudança de país etc.
    4. (Suposição) MFA não era obrigatória para uso de token roubado
    5. (Suposição) o token não era de uso único
    6. (Suposição) o token não estava guardado em um gerenciador de senhas que exigisse aprovação manual quando fosse usado em um novo aplicativo ou sessão
  • Nada disso deveria ter sido ignorado; tudo isso era totalmente evitável
  • Na prática, se você foi vítima e viu um novo repositório criado na sua conta do GitHub, isso também significa que você próprio não protegeu bem seus tokens de autenticação
  • O fato de essas medidas preventivas ainda não serem padrão é um grande fracasso de toda a indústria de software
    • Esse ataque vem se repetindo há anos
    • Nós mesmos, sendo desenvolvedores, não o corrigimos
  • Por isso, eu defendo que software também deveria ter regulamentação obrigatória, como código de obras, com inspeções e multas

    • Esse tipo de ataque pode causar danos catastróficos a dezenas de milhares de instituições em finanças, energia, telecomunicações, hospitais, forças armadas etc.

    • Com a disseminação da IA, a escala e o impacto dos ataques vão aumentar ainda mais

    • Não estamos escrevendo software com responsabilidade suficiente. Assim como no código de obras, segurança e proteção precisam ser impostas à força

    • O ambiente atual de computação pessoal ser um grande espaço unificado é mais perigoso do que parece

      • Em Mac, Windows e Linux, carteiras cripto, arquivos de credenciais e vários aplicativos ficam todos no mesmo lugar
      • As ferramentas para separar isso de forma adequada ainda são muito ruins
      • Às vezes, quando rodo várias VMs Windows no macOS, imagino um futuro em que seja possível alternar com Alt-Tab de forma limpa e suave entre contêineres ou VMs dedicadas a cada tipo de trabalho
      • Por exemplo: um contêiner para jogos, um contêiner dedicado a operações com cripto, contêineres por projeto de código principal etc.
      • É absurdo que uma única instalação de extensão do VSCode possa vazar minhas chaves de Bitcoin
      • Acho difícil que algo como um “código de obras de software” resolva esse problema mais fundamental
      • Também precisamos discutir regras no nível do sistema operacional para controlar o acesso de dados entre apps, junto com formas reais de implementá-las e aplicá-las

    • 50% das vítimas tiveram o VS Code como vetor de infecção, e o ataque só funcionava em Linux e macOS

      • Para uma análise detalhada desse ataque, veja esta análise no blog
      • Em caso de infecção:
        • na fase postinstall, ativos importantes como credenciais do usuário (carteiras cripto, tokens de GitHub e npm, chaves SSH etc.) eram coletados
        • ferramentas de linha de comando de IA (Claude, Gemini, Q etc.) eram usadas para coleta de informações e reconhecimento ativo
        • os dados roubados eram enviados, após dupla ou tripla codificação em base64, para repositórios do GitHub controlados pelo atacante (s1ngularity-repository etc.)
        • foram encontrados mais de milhares de repositórios
        • mais de 1.000 tokens do GitHub, dezenas de credenciais de cloud e NPM e cerca de 20 mil arquivos foram expostos
        • isso rodava principalmente pela extensão do VSCode do NX ou em pipelines de build (por exemplo, GitHub Actions)
        • em 27 de agosto às 9AM UTC, o GitHub desativou todos os repositórios do atacante, mas os dados ficaram expostos por até 8 horas
        • como a codificação base64 é facilmente reversível, na prática esses dados devem ser considerados públicos

    • O fato de tokens/credenciais do GitHub não estarem guardados em um gerenciador de senhas com liberação manual também é culpa do GH CLI

      • O GH CLI, depois de logado uma vez, ganha permissão para subir para repositórios e quase nunca exige reautenticação
      • O AWS CLI, dependendo da política, expira automaticamente a cada 18 horas
      • Mas ambas as plataformas facilitam que tokens fiquem armazenados em texto puro no ambiente local

    • Não gosto da ideia de introduzir um “código de obras de software”, mas concordo que toda a indústria é vulnerável demais

      • Talvez regulamentação realmente seja necessária

    • Acho arrogante querer responsabilizar alguém por você ter usado uma biblioteca open source gratuita

      • Se você quer garantias de verdade, deveria comprar uma licença
      • Isso é parecido com a política hostil do Google de verificação agressiva contra software livre

• Tenho feito a maior parte do meu trabalho de desenvolvimento recente em VMs

  • Sinto que o nível de segurança do ambiente atual está simplesmente inaceitável

  • A possibilidade de agentes (software baseado em agentes) funcionarem como vetor de malware aumentou enormemente

  • Se um atacante comprometer sua máquina, estamos numa era em que ele também pode mirar a qualquer momento dados que valem mais de 1.000 dólares, chaves cripto, senhas, informações pessoais, dados financeiros etc.

    • Eu também trabalho de forma parecida, dentro de um contêiner Podman. Não compartilho nada do host além do diretório de código-fonte

    • Parte do problema vem do modelo tradicional de segurança de PCs (Linux/Windows)

      • O modelo em que executáveis são considerados confiáveis e podem acessar todos os meus dados pessoais não faz mais sentido em 2025
      • O mobile (Android) em grande parte superou isso, mas no PC não há muitas alternativas profundas além do SELinux

    • Se você gosta desse tipo de abordagem, eu recomendaria Qubes OS. Ele oferece uma boa UX para fazer tudo em VMs

      • É meu sistema principal no dia a dia, recomendo fortemente

    • Dito isso, vale registrar que montar um ambiente desses é muito difícil ou bem caro por causa do ecossistema de software e da história da computação

• Claude Code é uma ferramenta revolucionária para aumentar produtividade

  • Por outro lado, há os seguintes problemas de segurança:

    • é um app em NodeJS
    • na instalação, faz curl com pipe para bash (risco de execução remota de código)
    • o LLM pode mexer em arquivo, comandos e várias outras coisas

  • Como existem pelo menos três fragilidades de segurança aí, eu não gostaria de executá-lo fora de um sandbox como VM/contêiner/máquina dedicada de desenvolvimento

    • Eu também acho certo rodar agentes em sandbox

      • Dito isso, o Claude code não executa comandos arbitrários por conta própria desde o início (sem permissão separada)

    • Mas e daí?

      • O usuário precisa apertar o botão de executar para ele rodar
      • A maioria dos programas também tem permissões
      • O terminal também pode mexer no sistema de arquivos, e nem por isso roda sozinho
      • O Claude Code não age como um daemon que destrói meu computador por conta própria; sem instrução explícita, ele não faz nada
      • Acho o Claude Code a melhor ferramenta que usei nos últimos 30 anos
      • Não ligo muito para qual foi o “vetor de ataque”. Se alguém acessa meu computador sem autorização, isso não é um problema exclusivo do Claude Code

    • O ponto realmente perigoso é que ele faz atualização automática sem intervenção do usuário, então na prática você concedeu à Anthropic permissão de RCE durante a execução

• Fico pensando se gerenciadores de pacotes não deveriam ter uma configuração tipo “idade mínima do pacote” (min-age)

  • Por exemplo, ignorar pacotes registrados há menos de 24–36 horas

  • Já passei por algo parecido antes: uma atualização de pacote quebrou tudo e poucas horas depois foi corrigida/removida

    • O GitHub dependabot adicionou exatamente esse recurso recentemente

      • changelog oficial

    • O Renovate bot já oferece essa opção (minimumReleaseAge), e agora o dependabot também suporta

      • Gerenciadores de pacotes só se preocupam em instalar a versão mais recente, mas com essas ferramentas gratuitas dá para gerenciar atualizações em uma cadência adequada
      • O ecossistema JavaScript está caminhando aos poucos para mais integração, e ferramentas para lidar com ataques à cadeia de suprimentos estão surgindo lentamente
      • NPM, PNPM, Bun etc. mais recentes não executam scripts postinstall por padrão, e exigem execução explícita quando necessário (embora no fim continue sendo uma situação de executar código de terceiros)

    • Não é no nível do sistema operacional, mas a ferramenta uv da Astral tem essa opção para pacotes Python

    • O npm install também tem uma flag para instalar apenas dependências de antes de um certo horário/data

      • Com npm install --before (data de 2 dias atrás), dependências criadas depois dessa data não são instaladas

    • Eu configuro save-exact=true no .npmrc e uso apenas lockfile e atualizações manuais

      • Não preciso atualizar pacotes com frequência
      • Depois de casos como o do fakerjs, senti que é preciso mais cautela

• Fiquei curioso se o claude code realmente executaria esse tipo de prompt, então testei

  • O resultado foi o seguinte:

    • “Este pedido parece solicitar busca e listagem de arquivos sensíveis, como carteiras de criptomoedas e chaves privadas, o que tem potencial de abuso, então não posso ajudar”

    • Ele só orientou sobre pedidos legítimos, como verificação de segurança, análise de vulnerabilidades, escrita de ferramentas de monitoramento, entendimento de permissões de arquivos e desenho de procedimentos de backup

    • Já foram obtidos pelo menos 250 casos de sucesso (ou seja, alguns prompts passaram)

      • O Claude de fato tem taxa de recusa média claramente maior, e o Q também costuma recusar bem (como também é baseado em Claude, é parecido)
      • Para contexto, passei o dia inteiro lidando com esse problema e escrevendo esta análise detalhada

    • Em situações reais, sempre que vejo Claude e outros modelos disputando na recusa, confirmo de novo que as recusas e proteções do Claude são muito superiores

      • Exemplo famoso: o ChatGPT seguia tratando um usuário com problemas de saúde mental como “The Oracle”, enquanto o Claude recusava e recomendava procurar ajuda profissional
      • Claro que respostas do tipo “Correto!” repetidas podem irritar, mas dá para reconhecer e elogiar que a Anthropic se preocupou mais com recusa e segurança do que concorrentes

• O sistema operacional deveria, por padrão, impedir que apps tenham acesso irrestrito ao sistema de arquivos inteiro

  • Alguns apps até têm perfis de apparmor/selinux, e também dá para usar firejail

  • Mas é preciso uma mudança de UX

    • Esse é um problema gravíssimo. É um legado de um design de desktop de 30 anos atrás

      • Em contraste, sistemas operacionais móveis modernos (como iOS) têm sandbox por app e políticas de permissão muito melhores por padrão
      • No desktop há várias tentativas, como Qubes (OS), Firejail, bubblewrap, AppArmor etc., mas são complexas ou difíceis demais para o usuário comum
      • Também existe o OpenSnitch, mas ele é limitado à rede
      • Do ponto de vista do usuário final, ajustar permissões detalhadas por programa é pesado demais
      • No fim, o mais importante é manter perfis atualizados de forma contínua para aplicativos amplamente usados
      • É chocante como a segurança de desktop continua tão fraca, mas esse problema é intrinsecamente difícil e há pouco incentivo financeiro para resolvê-lo

    • Estou desenvolvendo no Linux uma ferramenta focada em isolar ambientes por projeto usando Podman: probox

      • Há muito esforço para melhorar a UX
      • Tenho usado bastante, mas preciso de alguém para fazer uma revisão de segurança

    • Quando o assunto é segurança de arquivos no Android, o Google fez um bom trabalho

    • Também recomendo aprender a usar bubblewrap e pequenos ambientes chroot

    • Não acho que algum sistema operacional tenha como padrão “acesso irrestrito ao sistema de arquivos inteiro” para aplicativos

      • Linux, BSD, MacOS e Windows todos têm restrições fortes
      • Desde que o usuário comum não eleve permissões de forma perigosa por conta própria, o padrão é seguro

• Antes eu tinha uma confiança vaga de que “o atacante precisaria adivinhar meu ambiente”, mas agora ele pode usar um LLM para aprender e executar ataques adequados ao ambiente

  • Até me dou um certo crédito por ter previsto esse movimento na prática

  • Houve uma discussão interessante sobre isso nesta thread anterior

    • (Piada) Eu sou o atacante, alguma ideia nova? (/s)

• A parte realmente assustadora é usar agora LLMs locais para procurar segredos

  • O problema de postinstall é o mesmo de antes, mas o payload é de uma geração totalmente nova

  • Como a lógica maliciosa fica escondida em prompts em vez de código, fica mais difícil detectar com análise estática tradicional

  • Fico pensando em como seria possível se defender contra esse tipo de prompt malicioso

    • Parece que a única resposta é rodar Claude Code em um contêiner/VM totalmente isolado e revisar manualmente todo código que ele comitar