Full Report
PrefaceHey there! After quite some time the second part will be finally published :) !Sorry for the delay, real life can be overwhelming..Last time I have introduced this series by covering Data Execution Prevention (DEP). Today we're dealing with the next big technique. As the title already
Analysis Summary
# Tool/Technique: Stack Canaries (Stack Cookies)
## Overview
Stack Canaries (SC), also known as Stack Cookies, are an exploit mitigation technique designed to detect and prevent buffer corruption exploits, specifically stack smashing attacks that aim to overwrite the function return address on the stack. They work by placing a known value (the canary) between local variables/buffers and control data like the return address. Before a function returns, the canary's integrity is checked; if it has been modified, the program terminates, indicating a potential malicious overwrite attempt.
## Technical Details
- Type: Technique (Exploit Mitigation)
- Platform: Primarily discussed in the context of Linux systems using GCC, but the concept applies broadly to compiled languages (C/C++).
- Capabilities: Detects overwrites of buffer contents that spill over to the return address area on the stack.
- First Seen: StackGuard, the first implementation on Linux, appeared in 1997 with patches for GCC.
## MITRE ATT&CK Mapping
The primary focus is prevention/detection of control flow hijacking via stack corruption.
- **TA0005 - Defense Evasion** (Indirectly, as it prevents successful execution of the attack payload)
- **T1562 - Impair Defenses**
- T1562.001 - Impair Defenses: Disable or Modify Tools (Canary check failure causes termination, acting as a successful defense/impairment to the attack progression.)
- **TA0004 - Privilege Escalation** (Common goal of stack smashing)
- **T1078 - Valid Accounts** (Not directly applicable, but the successful exploit often leads here)
- **T1021 - Remote Services** (Not directly applicable)
*(Note: MITRE ATT&CK is more focused on adversary actions. Stack Canaries fit best as a **Defensive Technique** against execution or persistence goals.)*
## Functionality
### Core Capabilities
- **Canary Placement:** A filler word (the canary value) is placed on the stack between buffers/local variables and the saved frame pointer/return address for every function call (if the correct compiler flag is active).
- **Integrity Check:** Upon nearing a return instruction, the integrity of the stored canary value is verified against the value placed before execution.
- **Termination:** If the canary value has changed, program execution is immediately terminated to prevent the corrupted control flow from executing.
### Advanced Features
- **Terminator Canaries:** Canaries that contain specific byte sequences (like `0x00`, `0x0d` (CR), `0x0a` (LF), `0xff` (EOF)). When string functions like `strcpy` encounter these, they stop processing, effectively preventing the overflow from crossing the canary boundary.
- **Random Canaries:** Canaries generated using a high-entropy source, such as `/dev/urandom` or by hashing the time of day if `/dev/urandom` is unavailable. This makes it exceedingly difficult for an attacker to guess the correct value to use when overwriting the stack.
## Indicators of Compromise
Since this is a mitigation technique, IoCs relate to the *failure* of the mitigation, which results in a crash:
- File Hashes: N/A (Technique)
- File Names: N/A (Technique)
- Registry Keys: N/A
- Network Indicators: N/A
- Behavioral Indicators: Sudden, unexpected program termination upon an apparent buffer manipulation or input handling operation, often logged as a segmentation fault or unhandled exception.
## Associated Threat Actors
This technique is a defense mechanism, hence it is not "used" by threat actors, but it is specifically designed to thwart common exploitation methods historically used by various attackers targeting C/C++ codebases. Bypassing stack canaries has been a focus for maturity in exploit development across many adversarial groups.
## Detection Methods
Detection focuses on observing the system's response to attempted overflows rather than the canary itself:
- **Signature-based detection:** Difficult, as successful execution looks like normal program flow until the return check. Detection focuses on recognizing known exploit code attempting to bypass mitigations.
- **Behavioral detection:** Monitoring for unexpected process termination following high volume data input or calls known to be susceptible to buffer overflows (e.g., `gets`, uncontrolled `strcpy`).
- **YARA rules:** Not applicable for detecting the mitigation itself.
## Mitigation Strategies
Stack Canaries are themselves a mitigation strategy against stack-based buffer overflows.
- **Prevention Measures:** Compiling code with canary protection enabled (e.g., GCC's `-fstack-protector` flags).
- **Hardening Recommendations:** Employing memory-safe languages (Rust, Go) or ensuring rigorous bounds checking on all input handling, even when canaries are present, as some advanced attacks can leak or bypass canaries.
## Related Tools/Techniques
- Data Execution Prevention (DEP)
- Address Space Layout Randomization (ASLR)
- Address Sanitizer (ASAN)
- StackGuard (The original implementation framework)