Open Enclave Critical Use-After-Free Fixed in 0.19.22
TL;DR
Maintainers of the Open Enclave SDK fixed three severe bugs that let a rogue host break Intel SGX enclave safety. Led by a critical use-after-free flaw (GHSA-2rx6-6737-vpgh, CVSS 9.3), the bugs allow code execution, memory leaks, and fake sealed data. Devs must update to Open Enclave 0.19.22 and rebuild their enclave files right away.
Why It Matters
Open Enclave is an open-source tool that helps coders build private apps for hardware enclaves like Intel SGX. In the SGX threat model, the enclave must guard its keys and memory even when an attacker owns the host OS. However, these three flaws let a rogue host break that core hardware wall.
Security researcher redthing1 found and reported all three flaws to the project devs. Furthermore, the public reports include working proof-of-concept (PoC) exploit files for all three bugs. In fact, the researcher tested the critical PoC on an unmodified signed enclave from a major live service. Currently, no active attacks in the wild have been confirmed. While exact install counts remain private, cloud firms and enterprise teams use the SDK on Linux and Windows hosts.
How the Attack Works
Attester Registry Use-After-Free (GHSA-2rx6-6737-vpgh)
First, GHSA-2rx6-6737-vpgh (CVSS 9.3) is a use-after-free bug (CWE-416) in the SGX attester list inside the trusted runtime. When the host calls oe_get_report_v2_ecall(), the enclave sets up the attester list and drops its lock. Then, it looks up the plugin pointer without locking the object. Because the standard platform.edl template imports this call, almost every SGX enclave with more than one thread is exposed.
Consequently, a rogue host can pause the report thread right after the lookup and run OE_ECALL_DESTRUCTOR on a second thread. That destructor frees the attester array while the paused thread still holds a stale pointer. Next, the host starts another ECALL to overwrite the freed heap memory with crafted input. Because the get_report pointer shares offset 0x28 with the RBP register field, the host can point the call to oe_continue_execution(). When the thread resumes, the host takes control of enclave registers to read memory, steal keys via EGETKEY, or fake SGX reports.
Collateral Heap Overread and Unseal Policy Bypass
Second, GHSA-vxrq-p5g4-m499 (CVSS 7.1) is an out-of-bounds read (CWE-125) in SGX quote verification collateral checks. During an OCALL, the host can return OE_OK while claiming a written byte size larger than the enclave buffer size. This missing check affects all seven collateral buffers. When oe_create_sgx_endorsements() copies data with that unchecked size, it reads up to 200 KiB past the heap buffer. The PoC uses this bug to leak 65,536 heap bytes and steal an X25519 private key.
Third, GHSA-crp7-6hh4-pgfx (CVSS 7.1) stems from weak checks (CWE-345) in oe_unseal(). When unsealing a data blob, the function reads the sgx_key_request_t header without forcing key_policy to pick MRENCLAVE or MRSIGNER. By setting key_policy to zero, a second rogue enclave on the same host can derive the exact same key via EGETKEY. It can then forge sealed data that the target enclave accepts.
Affected Versions
All three bugs affect Open Enclave SDK versions prior to 0.19.22 running on Intel SGX systems.
Patch and Mitigation Steps
Devs fixed all three bugs in Open Enclave version 0.19.22. Every enclave file links the trusted Open Enclave runtime directly. Therefore, updating the host SDK package alone does not protect live apps. Teams must update to Open Enclave 0.19.22, rebuild all SGX enclave files, and block trust in older enclave builds.
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
