CWE-120

O produto copia um buffer de entrada para um buffer de saída sem verificar se o tamanho do buffer de entrada é menor que o tamanho do buffer de saída.

Consequências comuns

• Integridade, Confidencialidade, Disponibilidade → Modificar Memória, Executar Código ou Comandos Não Autorizados
• Disponibilidade → Modificar Memória, DoS: Falha, Encerramento ou Reinicialização, DoS: Consumo de Recursos (CPU)

Mitigações

• Requisitos: Use uma linguagem que não permita a ocorrência dessa fraqueza ou que forneça construções que facilitem evitá-la. Por exemplo, muitas linguagens que realizam seu próprio gerenciamento de memória, como Java e Perl, não estão sujeitas a buffer overflows. Outras linguagens, como Ada e C#, tipicamente fornecem proteção contra overflow, mas essa proteção pode ser desabilitada pelo programado
• 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. Exemplos incluem a Safe C String Library (SafeStr) de Messier e Viega [REF-57], e a biblioteca Strsafe.h da Microsoft [REF-56]. Essas bibliotecas fornecem versões mais seguras de funções de manipulação de strings propensas a overflow.
• Operação, Construção e Compilação: Use mecanismos automáticos de detecção de buffer overflow oferecidos por certos compiladores ou extensões de compilador. Exemplos incluem: a flag /GS do Microsoft Visual Studio, a flag FORTIFY_SOURCE do GCC no Fedora/Red Hat, o StackGuard e o ProPolice, que fornecem diversos mecanismos, incluindo detecção baseada em canary e verificação de faixa/índice. O D3-SFCV
• Implementação: Considere aderir às seguintes regras ao alocar e gerenciar a memória de uma aplicação: - Verifique novamente se seu buffer é tão grande quanto você especifica. - Ao usar funções que aceitam um número de bytes a copiar, como strncpy(), esteja ciente de que, se o tamanho do buffer de destino for igual ao tamanho do buffer de origem, ele pode não terminar a string com NULL. - Verifique
• Implementação: Assuma que toda entrada é maliciosa. Use uma estratégia de validação de entrada do tipo "aceitar apenas o que é reconhecidamente bom", isto é, use uma lista de entradas aceitáveis que estejam estritamente em conformidade com as especificações. Rejeite qualquer entrada que não esteja estritamente em conformidade com as especificações, ou transforme-a em algo que esteja. Ao realizar a
• 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