CWE-78

O produto constrói todo ou parte de um comando do SO usando entrada influenciada externamente vinda de um componente upstream, mas não neutraliza ou neutraliza incorretamente elementos especiais que poderiam modificar o comando do SO pretendido quando ele é enviado a um componente downstream.

Essa fraqueza pode levar a uma vulnerabilidade em ambientes nos quais o atacante não tem acesso direto ao sistema operacional, como em aplicações web. Alternativamente, se a fraqueza ocorrer em um programa privilegiado, ela poderia permitir que o atacante especifique comandos que normalmente não estariam acessíveis, ou chame comandos alternativos com privilégios que o atacante não possui. O problema é agravado se o processo comprometido não seguir o princípio do menor privilégio, porque os comandos controlados pelo atacante podem ser executados com privilégios especiais do sistema, o que aumenta a extensão do dano. Há pelo menos dois subtipos de OS command injection: - A aplicação pretende executar um único programa fixo que está sob seu próprio controle. Ela pretende usar entradas fornecidas externamente como argumentos para esse programa. Por exemplo, o programa pode usar system("nslookup [HOSTNAME]") para executar o nslookup e permitir que o usuário forneça um HOSTNAME, que é usado como argumento. Os atacantes não conseguem impedir que o nslookup seja executado. No entanto, se o programa não remover os separadores de comando do argumento HOSTNAME, os atacantes poderiam inserir os separadores nos argumentos, o que lhes permite executar seu próprio programa após o nslookup terminar de executar. - A aplicação aceita uma entrada que ela usa para selecionar totalmente qual programa executar, bem como quais comandos usar. A aplicação simplesmente redireciona todo esse comando para o sistema operacional. Por exemplo, o programa pode usar "exec([COMMAND])" para executar o [COMMAND] fornecido pelo usuário. Se o COMMAND estiver sob controle do atacante, então o atacante pode executar comandos ou programas arbitrários. Se o comando estiver sendo executado usando funções como exec() e CreateProcess(), o atacante pode não conseguir combinar múltiplos comandos na mesma linha. Do ponto de vista da fraqueza, essas variantes representam erros distintos do programador. Na primeira variante, o programador claramente pretende que a entrada de partes não confiáveis faça parte dos argumentos do comando a ser executado. Na segunda variante, o programador não pretende que o comando seja acessível a qualquer parte não confiável, mas o programador provavelmente não considerou maneiras alternativas pelas quais atacantes maliciosos podem fornecer entrada.

Consequências comuns

• Confidencialidade, Integridade, Disponibilidade, Não Repúdio → Executar Código ou Comandos Não Autorizados, DoS: Falha, Encerramento ou Reinicialização, Ler Arquivos ou Diretórios, Modificar Arquivos ou Diretórios, Ler Dados da Aplicação, Modificar Dados da Aplicação, Ocultar Atividades

Mitigações

• Arquitetura e Design: Se de alguma forma for possível, use chamadas de biblioteca em vez de processos externos para recriar a funcionalidade desejada.
• Arquitetura e Design, Operação: Execute o código em uma "jail" ou ambiente sandbox semelhante que imponha limites rígidos entre o processo e o sistema operacional. Isso pode efetivamente restringir quais arquivos podem ser acessados em um determinado diretório ou quais comandos podem ser executados pelo software. Exemplos em nível de SO incluem o chroot jail do Unix, o AppArmor e o SELinux. Em ger
• Arquitetura e Design: Para quaisquer dados que serão usados para gerar um comando a ser executado, mantenha o máximo possível desses dados fora do controle externo. Por exemplo, em aplicações web, isso pode exigir armazenar os dados localmente no estado da sessão em vez de enviá-los ao cliente em um campo de formulário oculto.
• Arquitetura e Design: Para quaisquer verificações de segurança realizadas no lado do cliente, garanta que essas verificações sejam duplicadas no lado do servidor, a fim de evitar o CWE-602. Os atacantes podem contornar as verificações do lado do cliente modificando os valores após as verificações terem sido realizadas, ou alterando o cliente para remover completamente as verificações do lado do cl
• Arquitetura e Design: Use uma biblioteca ou framework comprovado que não permita a ocorrência dessa fraqueza ou que forneça construções que facilitem evitá-la. Por exemplo, considere usar o controle de codificação (Encoding) do ESAPI [REF-45] ou uma ferramenta, biblioteca ou framework semelhante. Isso ajudará o programador a codificar as saídas de uma maneira menos propensa a erros.
• Implementação: Embora seja arriscado usar strings de consulta, código ou comandos gerados dinamicamente que misturam controle e dados, às vezes isso pode ser inevitável. Coloque os argumentos entre aspas adequadamente e escape quaisquer caracteres especiais dentro desses argumentos. A abordagem mais conservadora é escapar ou filtrar todos os caracteres que não passem por uma allowlist extremamente