Dependency confusion: quando um pacote público se sobrepõe a um privado

O que é

Um instalador transforma um nome abstrato (spam) em um arquivo concreto de algum repositório. A documentação do pip afirma que, quando vários locais de pacotes estão configurados, não há prioridade entre eles: todos são consultados e a melhor correspondência de versão é escolhida. A PEP 708 descreve a consequência: cada repositório é um namespace próprio, os instaladores os unificam em um só e, quando o mesmo nome existe em dois repositórios com autores diferentes, torna-se possível um ataque de dependency confusion. O exemplo que motivou a proposta é o torchtriton do PyTorch, que deveria vir apenas do índice do próprio projeto; o nome não estava reservado no PyPI e foi publicado ali por um atacante. A documentação do pip avisa que usar --extra-index-url para pacotes que não estão no repositório principal é inseguro e menciona esse ataque. O mesmo padrão existe em outros ecossistemas, sempre que um nome interno pode ser registrado publicamente.

Por que importa

O ataque não exige acesso aos seus sistemas: um agente de build, o notebook de um desenvolvedor ou um job de CI com configuração de índice permissiva instala o pacote do atacante, cujos hooks de instalação são executados com as credenciais da build. Nomes internos vazam por manifestos, mensagens de erro e repositórios públicos, portanto obscuridade não é uma defesa.

Como aplicar

• Associe namespaces a registros. No npm, vincule um escopo a um registro (npm config set @myco:registry=https://...); a documentação afirma que um escopo aponta para exatamente um registro e que instalações e publicações desse escopo vão para ele. Publique pacotes internos apenas sob um escopo desse tipo.
• Em Python, evite --extra-index-url para pacotes privados. Use um único --index-url apontando para um índice privado que funcione como proxy do público e decida, por nome, qual origem é permitida, de modo que o instalador veja um único namespace.
• Reserve seus nomes internos no índice público com pacotes de placeholder, quando o ecossistema permitir.
• Fixe versões com hashes (pip install --require-hashes, lockfiles com campos de integridade) para que um artefato substituído falhe na verificação.
• Execute as builds com credenciais mínimas e rede de saída restrita, para que um hook de instalação malicioso tenha pouco a levar.
• Audite a configuração do instalador em imagens de CI e em scripts de configuração de desenvolvedores; a linha perigosa costuma ser aquela que alguém adicionou para conseguir instalar um pacote privado.

Armadilhas

A PEP 708 propôs metadados de repositório ("tracks" e "alternate locations") para que os instaladores detectassem automaticamente combinações inseguras; ela foi rejeitada após três anos em aceitação provisória porque as condições necessárias nunca foram atendidas, de modo que os usuários de Python precisam configurar a proteção por conta própria. A ordenação de versões não é uma defesa: o atacante escolhe a versão mais alta. Mirrors que unem namespaces reintroduzem o problema.