CWE-362

O produto contém uma sequência de código concorrente que requer acesso temporário e exclusivo a um recurso compartilhado, mas existe uma janela de tempo na qual o recurso compartilhado pode ser modificado por outra sequência de código operando concorrentemente.

Uma condição de corrida ocorre em ambientes concorrentes e é, efetivamente, uma propriedade de uma sequência de código. Dependendo do contexto, uma sequência de código pode assumir a forma de uma chamada de função, um pequeno número de instruções, uma série de invocações de programa, etc. Uma condição de corrida viola estas propriedades, que estão intimamente relacionadas: - Exclusividade - a sequência de código recebe acesso exclusivo ao recurso compartilhado, isto é, nenhuma outra sequência de código pode modificar propriedades do recurso compartilhado antes que a sequência original tenha concluído sua execução. - Atomicidade - a sequência de código é comportamentalmente atômica, isto é, nenhuma outra thread ou processo pode executar concorrentemente a mesma sequência de instruções (ou um subconjunto dela) contra o mesmo recurso. Uma condição de corrida existe quando uma "sequência de código interferente" ainda pode acessar o recurso compartilhado, violando a exclusividade. A sequência de código interferente pode ser "confiável" ou "não confiável". Uma sequência de código interferente confiável ocorre dentro do produto; ela não pode ser modificada pelo atacante e só pode ser invocada indiretamente. Uma sequência de código interferente não confiável pode ser escrita diretamente pelo atacante e, tipicamente, é externa ao produto vulnerável.

Consequências comuns

• Disponibilidade → DoS: Consumo de Recursos (CPU), DoS: Consumo de Recursos (Memória), DoS: Consumo de Recursos (Outro)
• Disponibilidade → DoS: Travamento, Encerramento ou Reinicialização, DoS: Instabilidade
• Confidencialidade, Integridade → Ler Arquivos ou Diretórios, Ler Dados da Aplicação
• Controle de Acesso → Executar Código ou Comandos Não Autorizados, Obter Privilégios ou Assumir Identidade, Contornar Mecanismo de Proteção

Mitigações

• Arquitetura e Design: Em linguagens que oferecem suporte a isso, use primitivas de sincronização. Envolva-as apenas em torno de código crítico para minimizar o impacto no desempenho.
• Arquitetura e Design: Use capacidades thread-safe, como a abstração de acesso a dados do Spring.
• Arquitetura e Design: Minimize o uso de recursos compartilhados a fim de remover a maior complexidade possível do fluxo de controle e reduzir a probabilidade de ocorrência de condições inesperadas. Além disso, isso minimizará a quantidade de sincronização necessária e pode até ajudar a reduzir a probabilidade de uma negação de serviço na qual um atacante possa ser capaz de acionar repetidamente um
• Implementação: Ao usar multithreading e operar sobre variáveis compartilhadas, use apenas funções thread-safe.
• Implementação: Use operações atômicas em variáveis compartilhadas. Desconfie de construções de aparência inofensiva, como "x++". Isso pode parecer atômico na camada de código, mas na verdade é não atômico na camada de instrução, pois envolve uma leitura, seguida de um cálculo, seguido de uma escrita.
• Implementação: Use um mutex, se disponível, mas certifique-se de evitar fraquezas relacionadas, como o CWE-412.