Reino: Environment
Esta seção contém tudo o que fica fora do código-fonte, porém que é essencial para a segurança do produto que está sendo criado. Como os problemas tratados neste domínio não são diretamente relacionados com o código-fonte, nós o separamos dos demais domínios.
Dockerfile Misconfiguration: Dependency Confusion
Abstract
Recuperar dependências de compilação usando uma versão não específica pode deixar o sistema de compilação vulnerável a binários mal-intencionados ou fazer com que o sistema experimente um comportamento inesperado.
Explanation
Dockerfiles podem especificar um intervalo ilimitado de versões para dependências e imagens de base. Se um invasor for capaz de adicionar versões mal-intencionadas de dependências a um repositório ou enganar o sistema de compilação para fazer o download de dependências de um repositório sob o controle do invasor, se o docker estiver configurado sem versões específicas das dependências, então o docker baixará e executará silenciosamente a dependência comprometida .
Esse tipo de fraqueza pode ser explorado como resultado de um ataque à cadeia de suprimentos em que os invasores podem aproveitar a configuração incorreta dos desenvolvedores, typosquatting [sequestro de URL] e podem adicionar pacotes mal-intencionados a repositórios de código-fonte aberto. Um ataque desse tipo explora a confiança nos pacotes publicados para obter acesso e exfiltrar dados.
No docker, a tag
Exemplo 1: A configuração a seguir instrui o Docker a escolher a imagem de base usando a versão mais recente do
O Docker não valida se o repositório configurado para suportar o gerenciador de pacotes é confiável.
Exemplo 2: A seguinte configuração instrui o gerenciador de pacotes
No
Esse tipo de fraqueza pode ser explorado como resultado de um ataque à cadeia de suprimentos em que os invasores podem aproveitar a configuração incorreta dos desenvolvedores, typosquatting [sequestro de URL] e podem adicionar pacotes mal-intencionados a repositórios de código-fonte aberto. Um ataque desse tipo explora a confiança nos pacotes publicados para obter acesso e exfiltrar dados.
No docker, a tag
latest indica automaticamente o nível de versão de uma imagem que não usa uma tag de resumo ou exclusiva para fornecer uma versão para ela. O Docker atribui automaticamente a tag latest como mecanismo para apontar para o arquivo de manifesto de imagem mais recente. Como as tags são mutáveis, um invasor pode substituir uma imagem ou camada usando uma tag latest (ou tags fracas, como imagename-lst, imagename-last, myimage).Exemplo 1: A configuração a seguir instrui o Docker a escolher a imagem de base usando a versão mais recente do
ubuntu.
FROM ubuntu:Latest
...
O Docker não valida se o repositório configurado para suportar o gerenciador de pacotes é confiável.
Exemplo 2: A seguinte configuração instrui o gerenciador de pacotes
zypper a recuperar a versão mais recente do pacote fornecido.
...
zypper install package
...
No
Example 2, se o repositório estiver comprometido, um invasor pode simplesmente fazer upload de uma versão que atenda aos critérios dinâmicos e fazer com que o zypper baixe uma versão mal-intencionada da dependência.References
[1] Best practices for writing Dockerfile
[2] Standards Mapping - Common Weakness Enumeration CWE ID 20
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[9] Standards Mapping - FIPS200 CM
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[13] Standards Mapping - OWASP Mobile 2024 M2 Inadequate Supply Chain Security
[14] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[15] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 020
[30] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.configuration.docker.dockerfile_misconfiguration_dependency_confusion