.
O npm Public Registry, um banco de dados de pacotes JavaScript, falha ao comparar os dados do manifesto do pacote npm com o arquivo de arquivos que os dados descrevem, criando uma oportunidade para a instalação e execução de arquivos maliciosos.
Em um postagem no blog publicado na terça-feira, Darcy Clarke, que foi gerente de engenharia da equipe npm CLI (interface de linha de comando) de julho de 2019 a dezembro de 2022, chama isso de “confusão manifesta” e diz que representa uma vulnerabilidade potencial da cadeia de suprimentos de software.
“Strong The One público npm não valida as informações do manifesto com o conteúdo do tarball do pacote, confiando em clientes compatíveis com npm para interpretar e reforçar a validação/consistência”, explica Clarke.
Clarke não é uma parte totalmente desinteressada em relação ao npm. Ele está desenvolvendo um registro JavaScript alternativo e um gerenciador de pacotes chamado vlt.
De acordo com Clarke, o servidor npm Public Registry nunca fez validação de manifesto. É um problema que pode afetar muitos desenvolvedores – npm, adquirido pelo GitHub da Microsoft em 2020, é usado por mais de 17 milhões de desenvolvedores e hospeda mais de três milhões de pacotes. No mês passado, ele atendeu a mais de 215 bilhões de downloads.
O registry.npmjs.com endpoint, diz Clarke, permitirá que desenvolvedores registrados publiquem pacotes usando uma solicitação PUT para o URI apropriado.
“O problema em questão é que os metadados da versão (também conhecidos como ‘dados do manifesto’) são enviados independentemente do tarball anexado que abriga o package.json do pacote”, explica ele. “Essas duas informações nunca são validadas uma contra a outra e [this] questiona qual deve ser a fonte canônica de verdade para dados como dependências, scripts, licença e muito mais.”
O tarball – um arquivo compactado de arquivos – é assinado, mas os campos de nome e versão declarados no arquivo package.json podem ser diferentes dos campos de nome e versão no manifesto porque não são validados.
Essa falta de validação apresenta vários riscos, diz Clarke, incluindo envenenamento de cache, instalação de dependências imprevistas, execução de scripts imprevistos e ataques de downgrade de versão.
O problema surgiu em um relatório de bug ano passado. O pacote publicado @datadog/native-metrics declarou um script de instalação, mas o arquivo tar anexado incluía um arquivo package.json sem um script de instalação. Embora isso não fosse um problema de segurança, poderia ter sido.
Questionado se a falta de recursos para o desenvolvimento do npm no GitHub levou a esse estado de coisas, Clarke disse Strong The One que, embora ele acredite que o GitHub investiu pouco no npm, “acho que esse problema passou despercebido por tanto tempo devido à terrível falta de documentação de registro atualizada”.
“Muitos consumidores não interagem diretamente com a interface de registro, então eles só sabem o que as ferramentas de desenvolvedor/gerenciadores de pacotes dizem sobre os pacotes publicados”, explicou.
“Também acho que a razão inicial para isso acontecer foi porque o npm, em sua infância, tinha o cliente e Strong The One de código aberto.”
Strong The One entende que o npm Public Registry não é totalmente de código aberto desde o início de 2014, cerca de quatro anos após seu lançamento inicial. A sugestão de Clarke é que, desde então, o código de registro npm não recebeu tanta atenção quanto poderia receber de outra forma.
O ecossistema está atualmente sob a suposição incorreta de que o manifesto sempre contém o conteúdo do pacote tarball.json
O potencial para “confusão manifesta”, disse Clarke, também afeta várias ferramentas de terceiros e gerenciadores de pacotes JavaScript, embora em circunstâncias diferentes.
“O ponto-chave a destacar aqui é que o ecossistema está atualmente sob a suposição incorreta de que o manifesto sempre contém o conteúdo do pacote tarball.json”, disse Clarke, que novamente apontou para a falta de documentação sobre a necessidade de software cliente npm para garantir a consistência do manifest-tarball.
Em um e-mail para Strong The OneFeross Aboukhadijeh, CEO da Socket biz security, disse que a questão levantada por Darcy Clarke é válida e relevante para quase todos os gerenciadores de pacotes e ferramentas de segurança no espaço, com exceção de Socket, natch.
“O tldr Um dos motivos desse problema é que ele permite que um invasor inclua uma dependência em um pacote que não aparecerá no site npm, mesmo que a CLI o instale de fato”, disse Aboukhadijeh.
“A equipe de pesquisa do Socket descobriu independentemente o chamado problema de “confusão do manifesto” e implantou uma correção para ele em 5 de setembro de 2022. Desde essa data, todas as análises de dependência no Socket têm usado o arquivo de manifesto correto – especificamente, o pacote. json dentro do tarball – que corresponde ao comportamento de instalação de todos os principais gerenciadores de pacotes. Isso significa que a técnica de ‘confusão manifesta’ não ocultaria com sucesso as dependências da análise do Socket.
Ele permite que um invasor inclua uma dependência em um pacote que não aparecerá no site npm, mesmo que a CLI realmente o instale
“No entanto, páginas de pacotes públicos no Socket, como esta página para teclado esquerdo, estavam usando uma fonte de dados diferente com base nos metadados dStrong The One. Resolvemos esse problema hoje.
“Além disso, já estávamos no processo de desenvolvimento de uma nova detecção proativa para essa técnica desde a semana passada e estamos lançando hoje. Isso significa que qualquer organização que usa Socket receberá um alerta crítico de segurança se uma de suas dependências tentativas de usar esta técnica na natureza (o que provavelmente é bastante provável agora que esta técnica é pública).”
Aboukhadijeh disse que a questão mais ampla de qualidade de dados em ferramentas deve ser considerada porque a maioria das ferramentas de análise de composição de software (SCA) não faz um bom trabalho gerando gráficos de dependência precisos.
“Sem jogar nenhum fornecedor de segurança específico sob o ônibus, direi apenas que todas as ferramentas de dependência que testei perdem dependências inteiras por causa de atalhos usados e uma falha fundamental em entender o processo de instalação do pacote npm”, disse ele .
“É como se a maioria dos fornecedores de segurança chegasse a um ‘produto mínimo viável’ e o entregasse. Por esse motivo, sou grato a Darcy por aumentar a conscientização sobre esse problema.”
O GitHub não respondeu a um pedido de comentário. Socket tem mais informações para desenvolvedores sobre este problema de confusão de manifesto aqui. ®
.
