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.