CWE-427

O produto usa um caminho de busca fixo ou controlado para encontrar recursos, mas uma ou mais localizações nesse caminho podem estar sob o controle de atores não pretendidos.

Embora essa fraqueza possa ocorrer com qualquer tipo de recurso, ela é frequentemente introduzida quando um produto usa um caminho de busca de diretórios para encontrar executáveis ou bibliotecas de código, mas o caminho contém um diretório que pode ser modificado por um atacante, como "/tmp" ou o diretório de trabalho atual. Em sistemas baseados em Windows, quando a função LoadLibrary ou LoadLibraryEx é chamada com um nome de DLL que não contém um caminho totalmente qualificado, a função segue uma ordem de busca que inclui dois elementos de caminho que podem ser descontrolados: - o diretório a partir do qual o programa foi carregado - o diretório de trabalho atual. Em alguns casos, o ataque pode ser conduzido remotamente, como quando são usados compartilhamentos de rede SMB ou WebDAV. Uma ou mais localizações nesse caminho poderiam incluir a raiz da unidade do Windows ou seus subdiretórios. Isso frequentemente existe em código baseado em Linux que presume a natureza controlada do diretório raiz (/) ou de seus subdiretórios (/etc, etc.), ou em código que acessa recursivamente o diretório pai. No Windows, a raiz da unidade e alguns de seus subdiretórios têm permissões fracas por padrão, o que os torna descontrolados. Em alguns sistemas baseados em Unix, um PATH pode ser criado contendo um elemento vazio, por exemplo, ao emendar uma variável vazia no PATH. Esse elemento vazio pode ser interpretado como equivalente ao diretório de trabalho atual, que pode ser um elemento de busca não confiável. Em frameworks de gerenciamento de pacotes de software (por exemplo, npm, RubyGems ou PyPi), o framework pode identificar dependências de bibliotecas de terceiros ou de outros pacotes e, em seguida, consultar um repositório que contenha o pacote desejado. O framework pode buscar em um repositório público antes de um repositório privado. Isso poderia ser explorado por atacantes ao colocar um pacote malicioso no repositório público que tenha o mesmo nome de um pacote do repositório privado. O caminho de busca pode não estar diretamente sob controle do desenvolvedor que depende do framework, mas essa ordem de busca contém, efetivamente, um elemento não confiável.

Consequências comuns

• Confidencialidade, Integridade, Disponibilidade → Executar Código ou Comandos Não Autorizados

Mitigações

• Arquitetura e Design, Implementação: Fixe no código (hard-code) o caminho de busca para um conjunto de valores reconhecidamente seguros (como diretórios do sistema), ou permita que sejam especificados apenas pelo administrador em um arquivo de configuração. Não permita que essas configurações sejam modificadas por uma parte externa. Tenha cuidado para evitar fraquezas relacionadas, como o CWE-426
• Implementação: Ao invocar outros programas, especifique-os usando nomes de caminho totalmente qualificados. Embora essa seja uma abordagem eficaz, código que usa nomes de caminho totalmente qualificados pode não ser portável para outros sistemas que não usem os mesmos nomes de caminho. A portabilidade pode ser melhorada localizando os caminhos totalmente qualificados em um local centralizado e fac
• Implementação: Remova ou restrinja todas as configurações de ambiente antes de invocar outros programas. Isso inclui a variável de ambiente PATH, a LD_LIBRARY_PATH e outras configurações que identificam a localização de bibliotecas de código, além de quaisquer caminhos de busca específicos da aplicação.
• Implementação: Verifique seu caminho de busca antes de usá-lo e remova quaisquer elementos que sejam provavelmente inseguros, como o diretório de trabalho atual ou um diretório de arquivos temporários. Como essa é uma abordagem de lista de negação (denylist), ela pode não ser uma solução completa.
• Implementação: Use outras funções que exijam caminhos explícitos. Fazer uso de qualquer uma das outras funções prontamente disponíveis que exigem caminhos explícitos é uma forma segura de evitar esse problema. Por exemplo, system() em C não exige um caminho completo, pois o shell pode se encarregar de encontrar o programa usando a variável de ambiente PATH, enquanto execl() e execv() exigem um cam