This is a heap buffer overflow in ntfs.sys, one of the Windows kernel drivers, which was patched in June 2021. Heap vulnerabilities in the kernel are notoriously unreliable and hard to exploit, particularly given recent mitigations in Windows 8 and then later in Windows 10 that have introduced additional randomness to the kernel heap as well as additional state checks that will result in Windows terminating immediately if data does not look to be valid. Therefore realize that whilst this exploit has been exploited in the wild, I would imagine the reliability may be questionable or there may have been considerable work done behind the scenes to make the exploit more reliable.

In any case, the affected function is NtfsQueryEaUserEaList() in ntfs.sys which processes a list of extended attributes (this is where the ea part of the function name comes from) for a file and saves the retrieved values to a buffer. The problem here though is that users can make a Windows system call to access this function and NtfsQueryEaUserEaList() and its possible to control the size of the output buffer. However the output buffer’s size has to be 32 bit aligned. This causes an issue as whilst the code does check to make sure the output buffer can hold the content of the extended attribute list with padding, it doesn’t check for integer underflows, meaning that the check is done as though the number was an unsigned integer, yet when copying memory its treated as a signed integer, which can result in the number underflowing and becoming a large positive number, such that a lot of memory is copied into a very small buffer.

This is a particularly interesting case as most of the time when one combines an integer underflow/overflow with a heap buffer vulnerability, things don’t tend to pan out so well due to the user corrupting too much memory to reliably control the heap. This can cause issues later on when Windows checks the heap state and suddenly finds everything is trashed, resulting in a BSOD if one corrupts kernel heap memory. For this reason, I’m interested to see how the attackers actually managed to accurately control heap memory in this scenario to exploit the vulnerability.

From the advisory we are given some hints that the Windows Notification Facility (WNF) was used along with this vulnerability to get arbitrary memory read and write primitives, which is a new kernel exploitation strategy I have not heard about before. It appears this was also new to Kaspersky as well as they mention they will be publishing more information about this technique in the future.

Additionally, showcasing the sophistication of the attackers who exploited this vulnerability, they also used a rarely used PreviousMode overwrite instead of stealing overwriting the Token field of the EPROCESS structure to steal the token. As mentioned at https://github.com/oct0xor/presentations/blob/master/2019-02-Overview%20of%20the%20latest%20Windows%20OS%20kernel%20exploits%20found%20in%20the%20wild.pdf, this field controls which mode the kernel was in prior to performing a system call. This can allow an attacker to perform sensitive actions by essentially tricking the OS into thinking a system call was made from kernel mode when in reality it was not.