Kingdom: Time and State

Distributed computation is about time and state. That is, in order for more than one component to communicate, state must be shared, and all that takes time.

Most programmers anthropomorphize their work. They think about one thread of control carrying out the entire program in the same way they would if they had to do the job themselves. Modern computers, however, switch between tasks very quickly, and in multi-core, multi-CPU, or distributed systems, two events may take place at exactly the same time. Defects rush to fill the gap between the programmer's model of how a program executes and what happens in reality. These defects are related to unexpected interactions between threads, processes, time, and information. These interactions happen through shared state: semaphores, variables, the file system, and, basically, anything that can store information.

Race Condition: Signal Handling

Abstract
Installing the same signal handler for multiple signals can lead to a race condition when different signals are caught in short succession.
Explanation
Signal handling race conditions can occur whenever a function installed as a signal handler is non-reentrant, which means it maintains some internal state or calls another function that does so. Such race conditions are even more likely when the same function is installed to handle multiple signals.

Signal handling race conditions are more likely to occur when:

1. The program installs a single signal handler for more than one signal.

2. Two different signals for which the handler is installed arrive in short succession, causing a race condition in the signal handler.

Example: The following code installs the same simple, non-reentrant signal handler for two different signals. If an attacker causes signals to be sent at the right moments, the signal handler will experience a double free vulnerability. Calling free() twice on the same value can lead to a buffer overflow. When a program calls free() twice with the same argument, the program's memory management data structures become corrupted. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack.


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

int main(int argc,char* argv[]) {
...
signal(SIGHUP,sh);
signal(SIGTERM,sh);
...
}
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 362, CWE ID 364
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [22] CWE ID 362
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [21] CWE ID 362
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-003178
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 21.5
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 18-7-1
[13] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.11.2 Business Logic Architectural Requirements (L2 L3)
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[21] 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
[22] 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
[23] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 362
[24] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 362
[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3630.1 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3630.1 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3630.1 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3630.1 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3630.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3630.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3630.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001995 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001995 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001995 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001995 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001995 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001995 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001995 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001995 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001995 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001995 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001995 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001995 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001995 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001995 CAT II
desc.structural.cpp.race_condition_signal_handling