Talvez seja melhor não instalar novos softwares por enquanto

• Após o copy.fail, foram divulgadas vulnerabilidades adicionais no kernel Linux
• No momento, este é considerado um período em que um ataque à cadeia de suprimentos do NPM pode causar grandes danos
• Há a recomendação de tratar como exceção os patches do kernel Linux fornecidos pela distribuição
• Fora isso, é melhor suspender a instalação de novos softwares por cerca de uma semana
• Há uma observação de que, desde a publicação, os fatos ou a situação podem ter mudado, e que qualquer ponto que pareça incorreto ou pouco claro deve ser comunicado antes de se chegar a uma conclusão

[GN⁺]

Comentários do Hacker News

• Isso sempre foi um pesadelo inevitável. O número de pacotes cresceu demais e, com isso, a superfície de ataque da cadeia de suprimentos ficou tão grande que era só questão de tempo até isso estourar para todo mundo
  Mas era conveniente demais. Quem tentava alertar ou reduzir o risco era ignorado por pessoas que nunca experimentaram fazer de outro jeito, e "import antigravity" era fácil demais para abrir mão
  Parece que agora entramos na fase de “pagar o preço”

  • Em uma empresa, a operação era realmente conservadora. Todos os componentes externos tinham versão fixada, não eram atualizados sem revisão e normalmente passavam por um bom período de estabilização
    Quase tudo era compilado a partir do código-fonte, incluindo compiladores e kernel, e os servidores/infra de build não tinham acesso nenhum à internet; também havia um processo para incorporar mudanças. As CVEs relacionadas eram revisadas conforme eram divulgadas para decidir se se aplicavam a nós e como mitigar ou tratar cada caso
    Na empresa para a qual fui depois, os builds tinham acesso à internet e fazíamos upgrade assim que saía uma nova versão. As pessoas consideravam isso uma boa prática porque trazia as correções de bugs mais recentes, e a revisão de CVEs ficava com a equipe de segurança
    Depois, em uma startup, havia uma mistura de várias práticas. Tinha coisas muito boas, mas também uma grande dívida de CVE. Por exemplo, aplicavam secure boot e disco criptografado nos servidores, e tinham uma noção bem razoável de segurança nas comunicações entre componentes
    Todo mundo acha que está fazendo certo. É quase impossível convencer o pessoal do “faz upgrade sempre” de que existe o risco de introduzir novos problemas. A indústria precisa de um conjunto melhor de práticas, e eu pessoalmente acho melhor a forma como a primeira empresa gerenciava dependências. No geral, as práticas de segurança eram bem sólidas e o produto era realmente seguro
  • Abrindo a caixa de Pandora, fico pensando: e se o efeito líquido de expor todos esses vetores de ataque desconhecidos for esvaziar o estoque de vulnerabilidades guardadas por agências de inteligência do mundo todo?
    Todo software útil acabaria passando por fuzzing, testes baseados em propriedades e verificação formal, e todo mundo que procura vulnerabilidades teria de voltar à estaca zero
    Claro, isso pressupõe que a gente sobreviva ao intervalo em que os países despejam o que restou de seus recursos contra seus piores inimigos. Ou então talvez a gente acabe se batendo com ossos de animais
  • Há anos quero um modelo de segurança baseado em capacidades, e já discuti isso aqui antes. Capacidades seriam algo como ponteiros de objetos com permissões associadas, parecidos com descritores de arquivo do Unix
    No nível do sistema operacional, um programa em execução receberia tokens de capacidade do shell ou do lugar de onde foi executado, e toda system call precisaria receber uma capacidade como primeiro argumento. Então "open path /foo" viraria open(cap, "/foo"). Essa capacidade poderia representar qualquer coisa: um sistema de arquivos falso, um ramo do sistema de arquivos real, um sistema de arquivos em rede etc., e o programa não precisaria saber em que sandbox está vivendo
    No nível de biblioteca/linguagem, ao importar bibliotecas de terceiros como módulos npm, seria preciso passar capacidades no momento do import ou em cada ponto de chamada. Essa biblioteca não deveria ter acesso de leitura/escrita a todos os bytes do espaço de endereçamento do meu programa, nem poder agir como se fosse eu no meu computador. A pergunta central é: qual é o raio de explosão desse código? Quando a biblioteca que eu uso é maliciosa ou vulnerável, precisamos de um padrão razoável para limitar o estrago. Uma chamada lib::add(1, 2) não deveria levar ao comprometimento persistente do meu computador inteiro
    O seL4 já oferece capacidades em nível de sistema operacional, rápidas e eficientes, há muito tempo, e funciona bem. Em muitos casos é mais rápido que Linux e é muito útil para sandboxing transparente, drivers em espaço de usuário, comunicação entre processos e melhorias de segurança. Também dá para executar Linux como um processo sobre seL4. Eu queria um sistema operacional que tivesse todos os recursos de um desktop Linux, mas funcionasse como seL4
    Infelizmente, não parece existir uma linguagem de programação com capacidades no nível de linguagem do jeito que eu quero. Rust chega perto, mas seria preciso um jeito de impedir que crates de terceiros chamem qualquer código unsafe, incluindo unsafe trazido por dependências não confiáveis. Também seria preciso corrigir bugs antigos de soundness do Rust e ter uma biblioteca padrão baseada em capacidades. Coisas globais como open() / listen() deveriam desaparecer, restando apenas formas equivalentes a openat() e às outras partes correspondentes do sistema operacional
    Se os LLMs continuarem melhorando, em alguns anos, se ninguém fizer isso antes, pretendo mandar um LLM construir tudo isso. A segurança dos sistemas operacionais desktop modernos é uma piada
  • A maioria das pessoas, por padrão, não põe qualquer coisa na boca. Não ficam esperando sair o resultado positivo de uma cultura microbiológica para então rejeitar algo
    Precisamos de uma cultura de higiene para código, e isso não é tão diferente das normas que a maioria das culturas desenvolveu para comida. É uma combinação de heurísticas meio toscas, mas essa sensação de “eca” salva bilhões de pessoas
  • Há um ano, eu já levantava a ideia de que talvez fosse melhor escrever o código você mesmo em vez de trazer terceiros sempre que possível. Na época, só de considerar LLMs para preencher as lacunas já parecia heresia
    Agora estou reduzindo a exposição a dependências mais do que nunca, especialmente para coisas que dá para implementar com algumas centenas de linhas. Isso é literalmente uma mudança de paradigma

• A ideia de “esperar uma semana para instalar software” não funciona. Há apenas alguns meses, uma vulnerabilidade em larga escala atingiu a web, e foi um ataque com atraso temporal que ficou dormente por mais de um mês antes de ser executado
  Se todo mundo começar a esperar uma semana, os atacantes vão esperar duas. Cibercriminosos não precisam explorar imediatamente; só precisam conseguir explorar em algum momento. Muitos tipos de vulnerabilidade, como typosquatting, também não mudam com essa abordagem

  • O autor não parece estar dizendo para continuar adiando todas as atualizações, mas propondo uma única vez esperar uma semana até que correções e patches sejam distribuídos para essas vulnerabilidades específicas que foram divulgadas cedo demais desta vez. No restante, concordo
  • Acho que você entendeu o texto errado. A proposta não é esperar uma semana depois que um software for publicado para então instalá-lo. É simplesmente não instalar nada pelos próximos 7 dias a partir de agora
    Isso porque é bem provável que ainda não existam patches para essas vulnerabilidades e, mesmo que existam, há grande chance de aparecerem logo outras ainda piores
  • Então dá para esperar um mês ou dois. O ponto do período de espera não é impedir a execução de exploits já instalados, e sim evitar a instalação de novos exploits
  • Pacotes populares têm mais exposição. Quando o artefato é publicado, o mundo inteiro pode vê-lo, e dá para esperar que alguém compare as diferenças entre versões
    Mas, se não houver nenhum atraso, você pode ser atingido por um exploit que ainda ninguém viu
  • Em “alguns últimos meses”, todos os comprometimentos de dependências de que me lembro foram descobertos em minutos, não em horas. Foi o caso de litellm, axios, bitwarden CLI, imagens Docker da Checkmarx, Pytorch lightning e intercom/intercom-php
    Além disso, a descoberta desses comprometimentos não dependeu em nada de eles terem sido explorados de fato. Por isso não entendo a frase “se todo mundo esperar uma semana, os atacantes vão esperar duas”

• Como alternativa, você pode migrar para um sistema operacional como FreeBSD, que não adota uma postura YOLO com segurança
  Correções de segurança não são simplesmente jogadas no kernel do FreeBSD sem coordenação. Elas passam pela equipe de segurança do FreeBSD e, poucos minutos depois de o patch entrar na árvore src, atualizações binárias são distribuídas pelo FreeBSD Update e pelo pkgbase do 15.0-RELEASE
  Em termos de tempo, são alguns segundos até aparecer no Slack uma mensagem de “patch enviado”, de 10 a 30 segundos para o upload do patch, e até 1 minuto para a sincronização dos mirrors

  • Sou um pouco cético quanto a isso. Há alguns anos relatei uma vulnerabilidade à equipe de segurança do FreeBSD e, semanas depois, mandei até um follow-up, mas não recebi resposta
    Para ser justo, meu relatório era sobre algo que não era componente central e também não era fácil de explorar, mas Debian, OpenBSD, SUSE e Gentoo corrigiram tudo em menos de uma semana https://www.maxchernoff.ca/p/luatex-vulnerabilities#timeline
    Dito isso, não estou querendo julgar um sistema operacional inteiro pelo tratamento de um único relatório menor. Até porque, em tudo mais que vi, o FreeBSD parece levar relatórios de segurança bastante a sério. Só que a mesma lógica pode ser aplicada a bugs do kernel Linux. Esse tipo de má gestão de patch também é bem raro no Linux
  • Se a ideia é migrar para BSD por segurança, por que FreeBSD? O OpenBSD não seria o que tem fama de ser absurdamente seguro? Faz tempo que não acompanho esses projetos, por isso estou perguntando
  • O FreeBSD é bem relaxado com segurança, especialmente em defaults e configuração
    Tende a priorizar usabilidade acima de segurança. Um exemplo famoso está aqui: https://vez.mrsk.me/freebsd-defaults
    Sou grato a quem contribui para o projeto, mas, enquanto houver defaults ruins assim, não consigo recomendar a migração com a consciência tranquila
  • O FreeBSD nem tinha ASLR em espaço de usuário até 2019 e ainda não tem kASLR, que é outra dessas mitigação. Para quem se importa com segurança, não é um sistema operacional sério
    Se você quer FreeBSD com segurança, o caminho é usar o HardenedBSD do Shawn Webb
  • Sempre aparece alguém nessas discussões. Que bom que sua distro favorita é claramente mais segura. Mesmo que isso reduza exploits por um fator de um dígito, ainda devem sobrar alguns milhares. Ozymandias teria usado Gentoo

• Até especialistas em segurança precisam aceitar, a esta altura, que o nosso mundo está sobre um equilíbrio extremamente frágil. Acho que as pessoas subestimam muito isso
  Não só o mundo de TI, mas o mundo inteiro é construído sobre inúmeros equilíbrios muito frágeis. Sempre vai haver exploits de segurança. Não só em software, mas também no mundo físico. Teve até gente entrando escondida em conferência de segurança, e era só um youtuber. Tudo bem que não era um evento de altíssima segurança, mas foi o exemplo que me veio à cabeça. No fundo, na maioria dos casos, é muito fácil contornar segurança
  O que quero dizer é que, em essência, o nosso mundo funciona porque pelo menos a maioria das pessoas escolhe não abusar dessas brechas. A sociedade humana sempre funcionou assim, e provavelmente continuará assim

  • Lembro que houve uma moda entre influenciadores do Reino Unido de entrar em lugares com a tática da “escada e colete fluorescente” para mostrar como a segurança física era fraca https://www.youtube.com/watch?v=LTI0SeyhAPA
    Pelo que sei, um youtuber chamado Max Fosh conseguiu entrar repetidas vezes na International Security Expo. No Reino Unido, em https://www.youtube.com/watch?v=qM3imMiERdU, e nos EUA, em https://www.youtube.com/watch?v=NmgLwxK8TvA, ele usou os pseudônimos “Rob Banks” e “Nick Everything”, respectivamente
    Já estudei um pouco de cultura de segurança, e quase tudo acaba virando uma escala deslizante com segurança de um lado e conveniência/acessibilidade do outro. Quanto mais seguro, menos acessível; e o contrário também vale

• Já existe uma solução razoável para ataques de cadeia de suprimentos em gerenciadores de dependência como npm, PyPI e Cargo: configurar para instalar apenas versões de pacotes com alguns dias de idade
  Todos os grandes ataques recentes foram detectados e revertidos em menos de um dia, então isso teria evitado tudo com segurança. Esse comportamento deveria ser o padrão. Deixe os beta testers voluntários e as empresas de scanner de segurança usarem as versões mais novas por um dia antes. A ideia está aqui: https://cooldowns.dev/

  • Uma ferramenta como esta, mostrada no Show HN há 3 meses, parece mais apropriada: https://github.com/artifact-keeper
    É um gerenciador de artefatos. Ele deixa você buscar apenas o que foi aprovado. Dá para atualizar rápido quando for necessário e, quando precisar, usar de forma consistente versões estáveis e verificadas. Exige um pouco de configuração adicional, mas é algo fácil de fazer
    Já cheguei a criar e usar uma ferramenta meio improvisada com propósito parecido, e este é um bom projeto
  • Uma forma melhor é a empresa usar apenas repositórios validados por ela e impedir que qualquer pessoa instale diretamente de repositórios na internet
    Claro que, fora do ambiente corporativo, isso naturalmente funciona bem menos
  • Mas aí você também não receberia tarde demais as atualizações de segurança? Muitas vulnerabilidades ficam anos em produção antes de serem descobertas e corrigidas
    Depois que são descobertas, vem uma explosão imediata de exploits, e atualizações atrasadas dão mais tempo para atacantes animados
  • Pessoalmente, acho que o modelo mais sustentável é o de distribuições Linux / ports do BSD / Homebrew. Em vez de publicar uma nova biblioteca diretamente no registro público, você escreve um script de empacotamento que é revisado a cada nova mudança
    Outro modelo é o CPAN do Perl, que distribui apenas arquivos-fonte

• Quem adotou integração contínua e builds conteinerizados há relativamente pouco tempo deveria verificar se o sistema não está puxando latest de vários pacotes em cada build
  Nós criamos um contêiner-base com todas as dependências externas incluídas e só o atualizamos explicitamente quando decidimos que chegou a hora
  Assim, talvez a gente fique um pouco atrás da ponta de lança, mas assume muito menos o risco de uma vulnerabilidade de cadeia de suprimentos aleatória ser distribuída instantaneamente para o mundo inteiro

  • Você vai perceber que isso também reduz bastante o tempo de build do CI e as falhas instáveis
  • Além disso, é bom usar apenas repositórios internos

• É um texto opinativo ativamente prejudicial. É difícil entender a lógica
  Basta 45 segundos para verificar há quanto tempo as vulnerabilidades copyfail e dirtyfrag existem na prática. Isso já é mais tempo do que leva para ler o texto. Dirtyfrag pode afetar sistemas que remontam a 2017
  O problema não é software “novo”. E software realmente antigo tende a estar pior, porque já houve muito mais tempo para encontrar problemas

  • O texto original está sugerindo que, se acontecer um ataque de cadeia de suprimentos agora, isso pode ser muito ruim, então seria melhor reduzir esse risco evitando instalar/atualizar pacotes NPM

• Um dia alguém vai reconstruir a pilha inteira, do sistema operacional ao aplicativo, com upgrades de proof-carrying code
  A única forma de executar código confiável é com co-design e co-construção de prova e código

• Isso não vale só para software; na verdade vale para quase tudo
  Não lembro onde li isso, mas no fim acaba se resumindo à diferença entre necessidade e desejo
  Já usei essa regra ao decidir entre comprar carro novo ou usado, aspirador premium ou básico. O mesmo vale para trazer algum aparelho brilhante novo, algo novo para a stack tecnológica ou escolher uma stack nova

• Queria ajuda para entender o que é copyfail e como isso se conecta a pacotes NPM
  Pelo que entendi, copyfail parece ser um bug de kernel que permitiria a um pacote npm malicioso obter privilégios de root em um servidor Linux
  Então este seria o momento perfeito para atacantes mirarem pacotes NPM, já que ainda existem servidores sem patch
  O motivo de o conselho não ser simplesmente “atualize o kernel” é que novos problemas relacionados ainda continuam sendo descobertos?

  • Os patches para as vulnerabilidades mais recentes ainda nem saíram. Então, se houver um novo ataque de cadeia de suprimentos agora, seria um momento realmente ruim, porque praticamente qualquer sistema poderia acabar dando root
  • Ataques de cadeia de suprimentos via NPM se espalham muito rápido
    Se um pacote NPM popular for comprometido e incluir o exploit copy.fail, muitos sistemas ficariam vulneráveis a escalada de privilégios para root
  • O motivo de o conselho não ser “atualize o kernel” é que não há atualização. As vulnerabilidades mais recentes descobertas depois de copy.fail ainda não foram corrigidas