Full Report
The Adobe suite of products are immensly popular, especially their PDF readers. The PDF rendering process runs in a protected mode called a sandbox with restricted permissions. The PDF renderer has a brokered communication to a non-sandboxed process. So, to escape the sandbox, a vulnerability in the broker would need to be found. The communication channel is done via a shared memory buffer of 2MB. When the sandbox wants to access a resource, it edits the shared memory and emits a single to the broker; this happens in reverse as well. When the sandbox attempts to import a key, there are several values that are taken, two of which are used for a size calculation. The pointer size math with the offsets 0x10 and 0x14 is used for a dynamic heap allocation. Eventually, this size is used on a memcpy. The allocation size can be overflowed, leading to a smaller than necessary buffer. This primitive can be used to get an out of bounds write within the buffer. However, ASLR, control flow guard and some pointer encryption are being used. So, what do we do!? We create an encryption gadget. The pointer used for the CryptoProvider object is encrypted. Still, we can modify the function pointers on top of this object, this is nice. We cannot modify the encrypted object directly. However, there is a level of redirection. So, we can abuse the redirection of pointers to get the job done. First, we modify a CryptoProvider object to have a call to WinExec(). Next, we point the parameters for this call to a string we control in another cryptoprovider. By doing this, we have sidestepped the general pointer encryption. Additionally, calling WinExec() is allowed since this is course-grained CFI. I got a little lost on the exploit strategy to be honest. This is the best I could gather from it. Overall, this is an interesting post diving into Windows, sandboxes and bypassing of modern mitigations.
Analysis Summary
# Vulnerability: Integer Overflow in Microsoft Cryptographic Provider leading to Adobe Sandbox Escape
## CVE Details
- CVE ID: CVE-2021-31199
- CVSS Score: Information not explicitly provided, but context suggests **High** severity due to sandbox escape capability.
- CWE: CWE-190 (Integer Overflow or Wraparound) is highly likely given the description.
## Affected Systems
- Products: Microsoft Windows (specifically affecting the Microsoft Cryptographic Provider libraries, leading to an Adobe Sandbox escape when using Adobe products).
- Versions: Multiple Windows 10 versions (Specific versions not detailed in the summary, refer to Microsoft's advisory for exact patching details).
- Configurations: Exploitation targets the communication broker between the Adobe sandboxed process and the unsandboxed broker process. The flaw is within the Windows Cryptographic Provider library (`rsaenh.dll`).
## Vulnerability Description
The vulnerability is an **integer overflow** within the Microsoft Cryptographic Provider library, specifically in `rsaenh.dll`, during the `rsaenh.dll:ImportOpaqueBlob()` function, which is reached via `CryptSP:CryptImportKey()`.
When importing a key using a crafted opaque key blob, an incorrect size calculation is performed based on input values (where pointer size math with offsets 0x10 and 0x14 is used for dynamic heap allocation size). This size calculation can overflow, resulting in a **smaller than necessary heap allocation**. This leads to an **Out-of-Bounds (OOB) Write** primitive within the allocated buffer when a subsequent `memcpy` operation uses the input key data.
This OOB write is leveraged against the `HCRYPTPROV` object structure within the non-sandboxed broker process to hijack control flow and achieve code execution outside the Adobe sandbox.
## Exploitation
- Status: The description details a discovered exploit chain, implying exploitation is **Possible / PoC available** (as it describes the steps taken).
- Complexity: **High** (Requires multiple steps involving heap grooming, OOB writes to overwrite Crypto Provider function pointers, and bypassing mitigations like pointer encryption/ASLR/CFI via gadget chaining).
- Attack Vector: **Local/Adjacent** initially (requires the vulnerable process to be running and communicating, often initiated by opening a malicious PDF), culminating in Remote Code Execution (RCE) capability if triggered remotely via a crafted document.
### Exploitation Steps Summary (High Level)
1. **Heap Grooming**: Manipulate the broker process heap by creating holes in the allocation of `HCRYPTPROV` objects.
2. **OOB Write 1**: Use the integer overflow/OOB write primitive to overwrite the first `HCRYPTPROV` object, redirecting a function pointer (e.g., `CPGenRandom()`) to `ntdll!abs` via a controlled command string in an adjacent chunk.
3. **Trigger 1**: Call `CryptGenRandom()` to confirm the initial hijack (finding the overwritten object).
4. **OOB Write 2**: Use a second malicious key import to overwrite function pointers (`CPReleaseContext` and `CPGenRandom`) on a second adjacent `HCRYPTPROV` object. `CPReleaseContext` is overwritten with `kernel32:WinExec()`.
5. **Trigger 2 (Sandbox Escape)**: Call `CryptReleaseContext()` on the second overwritten object to execute `WinExec()`, achieving code execution outside the sandbox boundary.
## Impact
- Confidentiality: **High** (Sandbox escape allows access to underlying system resources).
- Integrity: **High** (Arbitrary code execution allows modification of system state).
- Availability: **High** (Achieving Remote Code Execution can lead to system compromise or denial of service).
## Remediation
### Patches
- Patches should be applied via the official Microsoft Security Update corresponding to **CVE-2021-31199**.
### Workarounds
- Reduce the trust level of documents viewed in Adobe Reader/Acrobat (e.g., disabling Protected Mode, if feasible, though this removes core security).
- Restrict the execution/network access of the Adobe Acrobat/Reader process via advanced endpoint protection rules until patching is complete.
## Detection
- **Indicators of Compromise (IoCs)**:
- Attempts within the Adobe process to interact with cryptographic functions (`CryptImportKey`, `CryptGenRandom`) in anomalous or rapid succession.
- Look for memory allocations in the broker process that are significantly smaller than the requested size based on input length, especially near `rsaenh.dll` structures.
- Post-exploitation, look for unauthorized calls to `WinExec()` originating from Adobe process memory space or child processes spawned by it.
- **Detection Methods and Tools**:
- Advanced Endpoint Detection and Response (EDR) tools capable of monitoring the control-flow integrity of system DLLs (`rsaenh.dll`, `CryptSP.dll`).
- Tracing IPC mechanisms (shared memory communication) between the Adobe sandbox and broker processes for unusual data patterns in key import operations.
## References
- Vendor Advisory: Search Microsoft Security Update Guide for **CVE-2021-31199**.
- Relevant Links:
- hxxps://blog.exodusintel.com/2023/04/06/escaping-adobe-sandbox-exploiting-an-integer-overflow-in-microsoft-windows/