Parallels Desktop uses a paravirtual PCI device called the Parallels ToolGate for communication between guest and host OS. The request format is a variable sized structure. The guest sends data to the host as inline bytes or pointers to paged buffers by writing the physical address of the structure.
If the size provided by the guest is more than the total size of the stack, it is possible to shift the Stack Pointer (RSP) into other regions of process memory. This vulnerability class is known as a
Stack Clash vulnerability.
When handling a specific operation, the application does not validate the ByteCount provided as part of the buffer. This value is then used to increase the size of the stack prior to writing data into it.
After finding this vulnerability, the authors wanted to do taint analysis and look for other cases of this bug. Most stack increases have a static size; for those that are not static, Binary Ninja marks this as UndeterminedValue. By searching for these occurrences it was possible to find 2 other variants of this bug in other places!
The authors dive into a mitigations to prevent Stack Clash issues. In particular, they mention called -fno-stack-check on MacOS and iOS. This mitigation is for calls to alloca or a variable length array. When incresing the stack, instrumentation is added to validate all allocation requests to be to valid stack memory, require an increase or crash safely. This was not included in the binary.
The author does not mention exploitation at all but points to the Qualys post linked to above; this post has a bunch of information relating to the exploitation of these types of bugs, specifically on Unix based systems, with many interesting examples. In order to exploit this, the Stack Guard page needs to be skipped. Even though we have a buffer length to jump to another part of memory, we cannot write to the bulk of it.