O caso do backdoor no xz como um microcosmo das interações em projetos de código aberto

• Há muitas análises sobre a vulnerabilidade no xz/liblzma, mas a maioria tende a pular a primeira etapa do ataque
  • O mantenedor original entrou em esgotamento, e apenas o atacante se ofereceu para ajudar (assim, o atacante herdou a confiança que o mantenedor original havia acumulado).
• O arquivo das threads de e-mail captura o momento em que essa etapa 0 estava acontecendo

O esgotamento do mantenedor e a entrada do atacante

• Surge um pedido que parece razoável ao mantenedor

  • "O XZ for Java ainda está sendo mantido? Fiz uma pergunta há uma semana e ainda não houve resposta."

• Essa pergunta faz o mantenedor sentir que precisa admitir um "fracasso"
  • Na realidade, o mantenedor não devia nada a ninguém e não fracassou em nada, mas foi assim que se sentiu
  • Porque decepcionar a "comunidade" é algo terrível
• O mantenedor admite que está "atrasado" e dá sinais de que precisa de ajuda
• Porém, naquela thread a ajuda não veio; em vez disso, o atacante do xz/liblzma se apresenta como alguém que o ajudou

  • "Jia Tan (o atacante desta vez) me ajudou... e talvez venha a ter um papel maior no futuro... meus recursos são muito limitados, então está claro que algo precisa mudar no longo prazo."

• O mantenedor menciona que seus recursos são limitados e que alguma mudança será necessária no longo prazo

O surgimento de um consumidor não colaborativo

• Um consumidor não colaborativo faz comentários críticos ao mantenedor

  • "Parece que não haverá progresso até que haja um novo mantenedor. ... O mantenedor atual perdeu o interesse ou não se importa mais com a manutenção. É triste ver um repositório assim."

• O mantenedor responde dizendo que não perdeu o interesse, mas que sua capacidade de manter o projeto estava limitada por questões de saúde mental, entre outras
• O mantenedor também relembra que se trata de um projeto de hobby não remunerado

O aumento das exigências

• Uma semana depois, o consumidor não colaborativo reaparece e volta a criticar o mantenedor.

  • "Você está ignorando inúmeras correções que estão apodrecendo aos poucos nesta lista de e-mails."

  • "Sinto muito pelas questões de saúde mental, mas é importante reconhecer seus próprios limites. Sei que este projeto é um hobby para todos os contribuidores, mas a comunidade quer mais."

• Essa pessoa até faz sugestões, mas não oferece ajuda concreta

  • "Que tal transferir a manutenção do XZ for C para que você possa se concentrar mais no XZ for Java? Ou então passar o XZ for Java para outra pessoa para focar no XZ for C? Se tentar manter os dois, talvez nenhum dos dois seja bem mantido."

• O mantenedor explica que não é fácil encontrar um novo co-mantenedor nem repassar o projeto por completo

A realidade dos projetos de código aberto

• Desenvolvedores de software não são engrenagens que se colocam e retiram à vontade
• A thread de e-mails termina com o consumidor reclamando e fazendo exigências sem oferecer nenhuma ajuda, enquanto apenas o atacante permanece

  • "Jia Tan talvez venha a assumir um papel maior no projeto no futuro. Ele tem ajudado bastante fora da lista e, na prática, já é um co-mantenedor. :-)"

• Essa thread de e-mails mostra, em miniatura, as interações em projetos de código aberto
• Consumidores impõem exigências aos mantenedores, e os mantenedores respondem de diferentes formas sob estresse e esgotamento
• Essa dinâmica precisa mudar

[GN⁺]

Comentários do Hacker News

• Há uma opinião de que os desenvolvedores parecem desperdiçar muita energia mental tentando ser gentis com os usuários e presumindo boa intenção de quem comenta. Esse tipo de observação aparece principalmente em projetos paralelos feitos por diversão, como emuladores e remakes de jogos. Esses projetos evitam mencionar doações para escapar de problemas relacionados a arrecadação ou direitos autorais. Há muito interesse no projeto, mas o interesse qualificado capaz de contribuir de fato é extremamente limitado. As conversas dos usuários são permitidas e incentivadas, mas às vezes podem ser percebidas como "sugestões" ou "exigências" que desmotivam os desenvolvedores. Manter a comunidade é importante, mas também existe preocupação em não excluir quem não contribui diretamente.

• A primeira etapa do problema foi um ataque de engenharia social em que o desenvolvedor de um projeto open source foi pressionado a entregar mais controle do repositório ao invasor.

• Como mantenedor de uma biblioteca open source voltada à segurança, toda vez que leio um PR sinto pesar a dúvida: "essa pessoa está tentando ajudar ou me usar?" Acho que desacelerar o desenvolvimento é a única solução, mas o sentimento que isso provoca é o mesmo descrito no artigo. Se existisse uma maneira simples de pedir ajuda a uma comunidade confiável de especialistas, isso seria sempre bem-vindo.

• Assim como em criptomoedas, IA e neste incidente, o maior problema acaba sendo a confiança. Criptomoedas tentam resolver o problema da confiança com código, LLMs tentam enganar com brilho para conquistar confiança, e os atacantes tiveram algum sucesso em lavar a confiança. As pessoas mais importantes da área técnica não estão pensando adequadamente sobre confiança. Nesse caso, há compreensão pela situação de um desenvolvedor open source cansado e não remunerado.

• Há uma pergunta sobre se um servidor SSH com port knocking configurado estaria seguro contra esse backdoor. Como o RCE só pode ser executado depois de se conectar ao servidor SSH, parece que não haveria problema se a porta estivesse escondida atrás de uma sequência razoável de TCP/UDP knocking. Port knocking não substitui uma configuração adequada de SSH, mas é útil como uma camada extra de defesa para prevenir problemas ou ganhar tempo de resposta quando surgem vulnerabilidades em SSH.

• Há um link para um problema relacionado a um patch específico do Linux no OpenSSH. Sem esse patch, o problema não teria acontecido. Não é um problema do OpenSSH, e sim do Linux.

• Há uma opinião de que as pessoas ainda tratam dependências rígidas e complexidade com descaso, mesmo depois do caso do left-pad. OpenSSH é um enorme paredão de código. Sistemas complexos são inerentemente difíceis de confiar, independentemente da linguagem em que foram escritos.

• Se um hacker chinês quisesse agir de forma maliciosa, por que usaria um nome/handle chinês? Seria melhor usar um nome em inglês ou europeu para ganhar mais confiança dos mantenedores de open source. Por outro lado, se um hacker não chinês quisesse agir de forma maliciosa, faria mais sentido usar um nome chinês (China é má etc.).

• A conta Jigar Kumar parece fazer parte do ataque de engenharia social e deveria ser vista com muita suspeita.

• Desenvolvedores de software não são peças substituíveis, e há quem esteja pensando em limitar as permissões para comentar ou participar da comunidade. Por exemplo, se o GitHub introduzisse um "gate", o primeiro poderia ser adicionar à suíte de testes um teste que gerasse um número de versão e um hash da saída dos testes. Ao adicionar esse número ao perfil, o GitHub poderia confiar que o usuário pelo menos baixou e executou make test. Isso demonstraria algum nível de comprometimento.