0
0
O mantenedor de um módulo de código aberto amplamente utilizado para ambientes Windows, Linux e Mac recentemente sabotou sua funcionalidade para protestar contra a guerra na Ucrânia e no processo focou a atenção mais uma vez nos problemas de segurança potencialmente graves ligados às dependências de código no software.
Brandon Nozaki Miller, autor do node-ipc, um módulo JavaScript para comunicação interprocesso que milhões de desenvolvedores usam ao construir software, recentemente inseriu código no software para excluir todos os arquivos em sistemas de desenvolvedores geolocalizados na Rússia e bielorrússia.
Mais tarde, ele removeu rapidamente versões do módulo contendo o código do limpador do registro npm JavaScript no qual ele estava disponível, mas depois publicou outro módulo chamado “peacenotwar” e tornou-o uma dependência do nó-ipc. Assim, os desenvolvedores que baixaram o node-ipc acabaram tendo um arquivo com a Ucrânia mensagens relacionadas à guerra colocadas em seu diretório de desktop. O módulo node-ipc tem uma média de mais de um milhão de downloads por semana, em todas as versões.
O fornecedor de segurança de aplicativos Snyk, que investigou o incidente esta semana, descreveu-o como um exemplo de um ato que prejudica a comunidade global de código aberto. “Este incidente de segurança envolve atos destrutivos de corromper arquivos em disco por um mantenedor e suas tentativas de esconder e reafirmar essa sabotagem deliberada de diferentes formas”, disse o diretor de advocacia de desenvolvedores da Snyk, Liran Tal, em um blog. “Embora este seja um ataque com motivações orientadas a protestos, ele destaca um problema maior enfrentado pela cadeia de fornecimento de software: as dependências transitivas em seu código podem ter um enorme impacto na sua segurança.”
O incidente de nó-ipc é o segundo nos últimos meses a destacar os sérios riscos que as empresas correm de usar componentes de código aberto e de terceiros para construir software.
Em janeiro, Marak Squires, o mantenedor de duas bibliotecas de código aberto muito amplamente utilizada — cores.js e faker.js — introduziu intencionalmente código nos módulos que fizeram com que os aplicativos que confiavam neles imprimissem a palavra “liberdade” várias vezes seguida de jargão. Sonatype, que mantém o repositório de pacotes Maven Central Java e investigou o incidente de Squires, descreveu as “cores” como tendo mais de 3,3 bilhões de downloads e como sendo usado em mais de 19.000 projetos e “faker” como tendo mais de 272 milhões de downloads e cerca de 2.500 projetos dependentes. Assim, milhares de candidaturas foram impactadas pela ação de Squires, que Sonatype supôs que poderia ter sido uma forma de protesto de Escudeiros sobre o que ele considerava como grandes empresas e projetos comerciais beneficiados gratuitamente de seu trabalho.
A análise de Dangerous Meddling
Snyk sobre o último incidente de nódulo-ipc mostrou que Miller, que usa a alça RIAEvangelista, publicou duas versões de nó-ipc contendo o código destrutivo (10.1.1 e 10.1.2) com apenas algumas horas de intervalo em 7 de março de 2021. Os módulos corrompidos estavam disponíveis para download no registro npm JavaScript por menos de 24 horas antes de serem removidos. Mesmo assim, o alto número de downloads associados ao node-ipc faz com que pelo menos alguns desenvolvedores que usam o módulo em seu código foram impactados, disse Tal em comentários ao Dark Reading.
“As versões destrutivas 10.1.1 e 10.1.2 foram removidas do registro de npmjs antes de [sermos] capazes de coletar quaisquer estatísticas de download para eles”, diz ele. No entanto, a filial de versão 10.x do node-ipc tem cerca de 3.000 downloads por semana, por isso é seguro assumir que quase a mesma quantidade de downloads continha o código do limpador.
Miller publicou o pacote peacenotwar no NPM um dia depois, em 8 de março. Ele descreveu o módulo como um protesto contra a agressão russa na Ucrânia, e como um exemplo “não destrutivo” de por que os desenvolvedores precisam exercer mais controle sobre módulos de nó. “[Isso] deve servir como um exemplo seguro de por que as equipes devem usar versões explícitas de dependência”, disse Miller em um thread do GitHub. “É sempre nossa escolha atualizar ou não.”
Tal diz que o módulo peacenotwar no início recebeu apenas dezenas e centenas de downloads, mas, uma vez adicionado como uma dependência da filial mainstream node-ipc, recebeu mais de 40.000 downloads. “Tenha em mente, porém, este módulo é o ‘protestware’ menos destrutivo, embora ainda bastante alarmante para os usuários finais.”
Em um comunicado, o CTO da Sonatype, Brian Fox, disse que os incidentes recentes mostram por que os desenvolvedores devem examinar os mantenedores ao escolher módulos de código aberto para uso. Ele recomendou que os desenvolvedores deveriam escolher quase exclusivamente o código entre projetos apoiados por fundações e não indivíduos. Escolher um projeto com apenas um mantenedor significa confiar em um único desenvolvedor, disse a Fox. Projetos de código aberto que são apoiados por uma fundação tendem a ter controles que tornam muito difícil para um único desenvolvedor alterar completamente o código por conta própria, observou ele.
“É impossível não olhar para o que aconteceu com a paz e o nó-ipc e imediatamente relacioná-lo com o que aconteceu com ‘cores’ e ‘faker’ que foi outro ato de protesto”, diz ele. “Você pode debater a validade deste protesto, mas esse tipo de comportamento contribui absolutamente para questões de confiança aparentes dentro do código aberto.”
Tal diz que pesquisas anteriores mostraram que as dependências aninhadas se compõem significativamente a cada módulo que é adicionado ao software que está sendo construído. Ele aponta para um estudo em 2019 que mostrou que os desenvolvedores instalando um pacote médio de npm confiam implicitamente em 80 outros pacotes devido a dependências transitivas. “Alguns pacotes altamente populares alcançam mais de 100.000 outros pacotes, tornando-os um alvo principal para ataques”, diz ele.
As preocupações com a segurança da cadeia de suprimentos aumentaram e devem estar no topo da mente para qualquer desenvolvedor, startup ou empresa, diz Tal. As preocupações com a segurança vão desde a reputação do mantenedor até o licenciamento, vulnerabilidades de segurança e manutenção do projeto. “Os desenvolvedores devem revisar cuidadosamente a pontuação geral de saúde do componente de código aberto, que abrange todas as características acima mencionadas e muito mais.”
FONTE: DARK READING