Reino: Time and State

A computação distribuída consiste em tempo e estado. Isto é, para que mais de um componente se comunique, é necessário compartilhar o estado, o que exige tempo.

A maioria dos programadores antropomorfiza seu trabalho. Eles enxergam um thread de controle executando todo o programa da mesma forma como enxergariam a si mesmos fazendo o trabalho inteiro por conta própria. Computadores modernos, entretanto, alternam entre tarefas com muita rapidez e, em sistemas multi-core, multi-CPU ou distribuídos, dois eventos podem ocorrer exatamente ao mesmo tempo. Defeitos rapidamente são postos nas lacunas entre o modelo do programador de como um programa é executado e o que ocorre na realidade. Esses defeitos estão relacionados com interações inesperadas entre threads, processos, tempo e informações. Essas interações ocorrem por meio de estados compartilhados: semáforos, variáveis, o sistema de arquivos e, basicamente, todas as coisas capazes de armazenar informações.

Race Condition: Signal Handling

Abstract
A instalação do mesmo manipulador de sinais para vários sinais pode provocar uma condição de corrida quando diferentes sinais são capturados em curta sucessão.
Explanation
Condições de corrida de manipulação de sinais podem ocorrer sempre que uma função instalada como um manipulador de sinais é não reentrante, ou seja, mantém um certo estado interno ou chama outra função que realiza isso. Essas condições de corrida são ainda mais prováveis quando a mesma função é instalada para lidar com vários sinais.

Condições de corrida de manipulação de sinais apresentam mais chances de ocorrer quando:

1. O programa instala um único manipulador de sinais para mais de um sinal.

2. Dois sinais diferentes para os quais o manipulador está instalado chegam em curta sucessão, causando uma condição de corrida no manipulador de sinais.

Exemplo: O código a seguir instala o mesmo manipulador de sinais simples não reentrante para dois sinais diferentes. Se um invasor fizer com que os sinais sejam enviados nos momentos certos, o manipulador de sinais passará por uma vulnerabilidade de liberação dupla. Chamar free() duas vezes no mesmo valor pode resultar em um buffer overflow. Quando um programa chama free() duas vezes com o mesmo argumento, as estruturas de dados de gerenciamento de memória desse programa se tornam corrompidas. Essa corrupção pode fazer com que o programa trave ou, em algumas circunstâncias, com que duas chamadas posteriores para malloc() retornem o mesmo apontador. Se malloc() retornar o mesmo valor duas vezes, e, mais tarde, o programa der ao invasor controle sobre os dados que são gravados nessa memória duplamente alocada, o programa se tornará vulnerável a um ataque de buffer overflow.


void sh(int dummy) {
...
free(global2);
free(global1);
...
}

int main(int argc,char* argv[]) {
...
signal(SIGHUP,sh);
signal(SIGTERM,sh);
...
}
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 362, CWE ID 364
[2] Standards Mapping - Common Weakness Enumeration Top 25 2022 [22] CWE ID 362
[3] Standards Mapping - Common Weakness Enumeration Top 25 2023 [21] CWE ID 362
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000366, CCI-003178
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 21.5
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 5.1, Rule 21.5
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 18-7-1
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-6 Configuration Settings (P1), SA-11 Developer Security Testing and Evaluation (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-6 Configuration Settings, SA-11 Developer Testing and Evaluation
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.11.2 Business Logic Architectural Requirements (L2 L3)
[12] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.3 - Terminal Software Attack Mitigation
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.3 - Terminal Software Attack Mitigation
[21] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 362
[22] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 362
[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3630.1 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3630.1 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3630.1 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3630.1 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3630.1 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3630.1 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3630.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001995 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001995 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001995 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001995 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001995 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001995 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001995 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001995 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001995 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001995 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001995 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001995 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001995 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001995 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001995 CAT II
desc.structural.cpp.race_condition_signal_handling