Mantenedor de software de código aberto desativa os pacotes npm colors e faker. E agora?

Em 8 de janeiro de 2022, o mantenedor do popular pacote npm de código aberto colors publicou colors@1.4.1 e colors@1.4.44-liberty-2, nos quais introduziu intencionalmente um commit problemático que adiciona um loop infinito ao código-fonte. O loop infinito é acionado e executado imediatamente quando o código-fonte do pacote é inicializado, causando uma negação de serviço (DoS) em qualquer servidor Node.js que o utilize.

Em resumo: A Snyk identificou uma vulnerabilidade de segurança de negação de serviço em colors@1.4.1, causada por este código vulnerável. Recomendamos fortemente que você volte para colors@1.4.0 e fixe as versões das dependências para evitar atualizações automáticas para a versão problemática. Também recomendamos migrar para outro pacote. Continue lendo para saber mais sobre o escopo, o impacto e as medidas de mitigação recomendadas.

Sobre colors

O pacote npm de código aberto colors recebe mais de 20 milhões de downloads por semana e é um projeto essencial do ecossistema para desenvolvedores de JavaScript e Node.js, impulsionando diversos projetos. Registros do GitHub mostram que o projeto colors é usado em mais de 4 milhões de outros projetos, e o npmjs.org indica que 18.962 outros pacotes dependem dele.

Confira alguns projetos que dependem de colors:

• O auxiliar de linha de comando prompt (~500 mil downloads semanais)

• Formatação de tabelas Unicode cli-table3 (~7 milhões de downloads semanais)

• O próprio aws-cdk da AWS (~2 milhões de downloads semanais)

Na prática, a versão com falha colors@1.4.1 afeta muitos usuários e não deve ser encarada levianamente. Segundo as estatísticas da página do pacote no npmjs, essa versão tinha sido baixada 95.397 vezes até a publicação deste artigo:

O código que causa o problema

O código problemático a seguir foi introduzido na biblioteca vulnerável colors:

1for (let i = 666; i < Infinity; i++;) {
2   if (i % 333) {
3       // console.log('testing'.zalgo.rainbow)
4   }
5   console.log('testing testing testing testing testing testing testing'.zalgo)
6}

Esse código de loop infinito, localizado no arquivo index.js do código-fonte do pacote, interrompe qualquer uso do pacote e imprime um texto zalgo bastante perturbador no terminal:

Dependo do pacote colors. O que devo fazer para mitigar o problema?

Se você foi afetado pelo incidente com colors por usar a versão com falha 1.4.1, recomendamos voltar para a versão mais recente conhecida como segura, colors@1.4.0, que não inclui o código problemático de loop infinito. Por exemplo, para fixar a versão estável e segura do pacote colors no arquivo package.json, substitua:

1"colors":"^1.4.0"

por:

1"colors":"1.4.0"

Para referência futura, recomendamos adotar as seguintes práticas recomendadas para gerenciar bibliotecas de código aberto em seus projetos:

1. Fixe as versões das dependências, seja no arquivo package.json ou usando um arquivo de lock. Isso ajuda a evitar a resolução de versões mais recentes no momento da instalação, que poderia instalar a versão corrigida 1.4.1 de colors, que introduziu o problema.

2. Este incidente deve levar você a considerar a migração para um pacote alternativo para lidar com cores, como chalk.

3. Analise os aspectos de manutenção e sustentabilidade dos pacotes de código aberto que você pretende usar e verifique se eles têm um modelo de governança adequado, com vários contribuidores, por exemplo.

Faker.js: o mesmo mantenedor, a mesma história?

Este caso vem na sequência de um incidente semelhante envolvendo o popular pacote npm faker (amplamente conhecido como Faker.js), mantido pela mesma pessoa. Muitos desenvolvedores usam o Faker para gerar grandes volumes de dados fictícios, algo comum em práticas de teste de software.

O Faker recebe 2 milhões de downloads semanais e também é uma dependência bastante popular em projetos JavaScript e Node.js. No entanto, em 5 de janeiro de 2022, o repositório de código aberto desse pacote no GitHub recebeu um commit forçado que reverteu completamente o código-fonte original do pacote:

Em seguida, a versão do pacote npm faker foi atualizada para 6.6.6 e publicada no registro público do npmjs como um pacote vazio, sem código-fonte.

O mantenedor abriu uma issue dizendo que não manteria mais o pacote gratuitamente:

Mais tarde, o autor removeu do GitHub o repositório que continha o projeto, provavelmente causando uma grande interrupção para milhares de desenvolvedores que usam o pacote e agora talvez precisem encontrar caminhos para migrar.

Mais tarde, publicou um artigo sobre o assunto em seu blog pessoal, detalhando as tentativas frustradas de monetizar o projeto ou conseguir patrocínio e afirmando que o modelo atual de doações é insustentável: “Como a maioria de nós, tenho pessoas que dependem de mim e contas para pagar”.

Como o mesmo mantenedor participa de cerca de 170 outros pacotes npm, essa história pode ainda não ter chegado ao fim.

Os riscos dos modelos de financiamento e governança do código aberto

Este caso faz parte de uma tendência mais ampla na comunidade de código aberto, relacionada à responsabilidade de empresas e organizações que dependem de código aberto em produção para criar seus produtos.

Após publicar o código problemático em colors, o mantenedor também abriu uma issue no GitHub para tratar do assunto. Nela, fez piadas sobre não conseguir encontrar a causa desse “bug” e não ter tempo para resolvê-lo.

Marak continua marcando outros desenvolvedores de Node.js bastante ativos para ajudar com o problema, mas nenhum deles tem acesso real ao repositório do projeto:

Esses incidentes acompanham uma tendência recente de discussão na comunidade de código aberto: cada vez mais mantenedores expressam sua insatisfação com empresas e organizações que monetizam e usam software de código aberto em seus produtos.

Em resposta às críticas ao código aberto após o Log4Shell, abordamos recentemente as dificuldades que os mantenedores enfrentam para manter softwares de código aberto saudáveis sem financiamento.

Podemos observar uma tendência contínua de mantenedores bloquearem completamente o acesso aos seus pacotes. Embora esse sentimento seja compreensível e os argumentos sejam válidos, é importante notar que bloquear o acesso a pacotes de código aberto também prejudica outros desenvolvedores e mantenedores desse tipo de software.

Adote as práticas recomendadas de segurança para código aberto

Usar software de código aberto exige que avaliemos adequadamente os riscos desses incidentes, além de outras questões de segurança e jurídicas, e estejamos preparados para lidar com elas à medida que surgirem. Melhor ainda é adotar práticas recomendadas para evitar e mitigar possíveis problemas de segurança na cadeia de suprimentos.

Recomendamos as seguintes práticas e leituras para ajudar você a se preparar melhor para situações como essa:

1. Analise as condições de manutenção e sustentabilidade dos projetos de código aberto. O Snyk Advisor é uma ferramenta que ajuda a avaliar a pontuação de saúde de um pacote.

2. 10 práticas recomendadas de segurança para npm aborda a importância de ativar a autenticação de dois fatores, fixar as versões das dependências usando arquivos de lock corretamente, entre outras medidas.

3. Saiba mais sobre como proteger sua cadeia de suprimentos de software moderna, incluindo temas como confusão de dependências, typosquatting e pacotes maliciosos.

4. Veja dicas práticas de como a Snyk ajuda a impedir pacotes maliciosos e ataques à cadeia de suprimentos