Definition
Comparing a value stored in a stack frame with a known good value in order to prevent or detect a memory segment overwrite.
How it works
This defense must be applied at compile-time, or via a patch to the program binary. Stack Frame Canary Verification inserts instructions at the prologue and epilogue of desired functions. In the prologue, a canary value, typically with the same size as the register size, is stored in the system of record and on the stack. Typically, the canary is loaded to where it has a memory address just below that of the saved instruction pointer and base pointer. In the epilogue, the canary value stored on the stack and, is compared to the canary value in the system of record. If the values are different, other techniques such as those in Process Eviction might be invoked, such as Process Termination to end the current process, or Executable Blacklisting to blacklist the potentially vulnerable or malfunctioning executable.
Stack Frame Canary Verification is commonly used to detect potential tampering of a saved register value on the stack before it has been restored. Examples of registers with values commonly saved to the stack include the instruction pointer and the base pointer.
The canary should be stored between where the start of a buffer overrun is likely, and the data to protect, in cases where the buffer size increases it will overwrite the data to be protected.
On most processor architectures, including x86, x64, and ARM, a "push" operation to store data to the stack grows the stack towards a lower memory address. As in these architectures, saved register values are stored to the stack at a point in time just before space is made for the local function variables, the saved register values have a higher address than that of the local function variables. Values at increasing indexes of a buffer are written to increasing memory addresses; therefore, an overwrite in the local variable buffer could overwrite saved register values, and a stack canary between these two would be useful in detecting an overwrite.
On some other processor architectures such as the B5000, the stack grows towards increasing memory addresses, and some architectures, such as System Z and RCA1802A, stack direction can be chosen. If the stack grows towards increasing memory addresses, while this architecture inherently provides more protection against a saved register being overwritten, other data including local function variables might be overwritten.
Considerations
There are several ways that the protection provided by a canary could be rendered ineffective.
Performing a malicious action before the canary is checked
If the attacker alters the memory in such a way that it performs a malicious action before the epilogue is called, then this protection will not be effective. This includes altering the logic of the program by altering the values of local variables stored on the function stack, or by causing an exception and exploiting the exception mechanism such as the SEH (Structured Exception Handling) mechanism on Windows.
Determining the canary value
Determining the canary value is possible through reading memory either for the code used to check the canary, or from the stored canary value itself in a stack frame.
Changing the canary value
A vulnerability such as a write-what-where condition that allows one to write data after the canary in the stack, would allow control of the value of the saved instruction pointer without needing to know the canary value.
Implementation perspective
Stack Frame Canary Validation should be treated as a technical defensive capability rather than a product checkbox. In practice, teams should define the protected scope, the conditions under which the technique acts, and the observable evidence that demonstrates the intended behavior. For this technique, likely engineering context includes Stack Frame.
Use the technique to increase the effort, prerequisites, or constraints an adversary must overcome before exploitation or misuse succeeds.
Questions to ask
- Which component, configuration, credential, interface, or behavior is being hardened?
- What secure baseline or policy defines the intended state?
- How are exceptions approved, time-limited, and reviewed?
- How is the hardened state verified after deployment and significant change?
Evidence and validation
- Approved hardening standards and configuration baselines
- Automated configuration or integrity assessment results
- Exception records with owners, rationale, and expiration dates
- Test results demonstrating that the intended restriction is enforced
Common failure patterns
- A secure setting is documented but not enforced consistently across the environment.
- Hardening breaks required functions and is permanently weakened through undocumented exceptions.
- Teams measure deployment of a product rather than verification of the hardened condition.
This implementation perspective is original Bare Metal Cyber educational content. It does not replace the official D3FEND definition or establish that a specific product implements the technique.
Technique hierarchy
Top-level family
Parent techniques
Direct child techniques
None listed at this level.
Artifacts and ontology entities
These relationships describe how D3FEND connects a defensive technique to artifacts or other ontology entities. They describe graph semantics, not a product certification.
Explicit technique relationships
Show inferred artifact relationship paths (1)
Offensive-technique relationships
These relationships are generated from D3FEND graph paths and are explicitly experimental. They should be treated as hypotheses for defensive analysis—not as proof that the technique prevents, detects, or removes an offensive behavior.
ATT&CK Enterprise (5)
ATT&CK for ICS (3)
Authoritative sources
- Open this technique on the official D3FEND website ↗
- Open the official ontology resources ↗
- /GS (Buffer Security Check) ↗Microsoft Docs · UserManualReference
- Security Technologies: Stack Smashing Protection (StackGuard) ↗Red Hat · Huzaifa Sidhpurwala · InternetArticleReference
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by The MITRE Corporation. MITRE D3FEND™ and the D3FEND logo are trademarks of The MITRE Corporation. MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation. Use of D3FEND source material is subject to the official Terms of Use.