CVE-2024-30085 is a heap-based buffer overflow in the Windows Cloud Filter Mini Driver. The driver works as part of a system to update and sync files locally with a remote server. The vulnerability works because two checks to prevent the buffer overflow are incomplete and can be bypassed. The attack is non-trivial and requires multiple heap sprays and overflows to gain both a read primitive and a write primitive. Because it is complex and requires access, it makes sense that the CVSS score is not higher. That said, Windows Workstations and servers from 2018 to 2023 are vulnerable, so the target surface is large.

The first inadequate check is a length check before calling memcpy to copy bitmap data associated with the reparse point. The destination buffer is of size 0x1000, and the data in question is a specific object, so the data will likely not exceed the size unless the object is maliciously-formed. The check is bypassed if the reparse point’s hasBuf value is false, and unfortunately, the value is controlled by a regular user. When the attacker creates the reparse point data, they can just set that flag to false and no bounds check will occur.
A second protection to bypass is that a file cannot be created and set as a reparse point within a sync root- unfortunately, this check takes place at the time a file is created. The bypass is simply to create the file in a directory, pass the check, and move the directory into the sync root, as required.
The weaponized PoC released for this exploit uses two separate buffer overflows to gain a read primitive, and then a write primitive. The first overflow sprays the heap with ALPC handle objects and _WNF_STATE_DATA objects, with the goal of creating a too-large _WNF_STATE_DATA object gaining access to an ALPC handle object which delivers both a leak for the current process’s security token and the ability to add a write primitive by inserting an ALPC_RESERVE object into a linked list.
A second spray and overflow is used to corrupt a second _WNF_STATE_DATA object with the goal of gaining access to a PipeAttribute structure that was sprayed into the heap. If an attacker gains access to a single PipeAttribute struct, they can add a new element in the linked-list of PipeAttribute kernel structures in user-land memory accessible to the attacking process. Gaining control of a PipeAttribute structure gives the attacker to perform arbitrary kernel memory reads using a technique outlined here: https://www.sstic.org/media/SSTIC2020/SSTIC-actes/pool_overflow_exploitation_since_windows_10_19h1/SSTIC2020-Article-pool_overflow_exploitation_since_windows_10_19h1-bayet_fariello.pdf
The arbitrary read allows the attacker to read data from the leaked ALPC handle table address (the first overflow) that gives the attacker the ability to read their own security token by following the address listed in the ALPC object it created.
Because the attacker also has control of the _WNF_STATE_DATA object overwriting the ALPC object, they can insert another ALPC object from user memory into the list, much the same way they did with the PipeAttribute structure, except that while the PipeAttribute structure gave the ability to read, the ALPC structure gives the ability to write, as the new controllable structure will send a message, but the attacker controls both the message to send and the address where the message should be written.
In one PoC, the attacker locates the system process’s token, reads it with the read primitive, and then places it in the message with the current process’s token address as the destination. A second PoC uses a hard-coded value for the token and overwrites it in the same way.