First part - Diffing

Using BinDiff with IDA Pro, patch diffing result with the following changes:

Three candidates come to the top:

• NtfsRenameToPrivateDir
• TxfAllocateAndStoreNameForTxLogging
• TxfAllocateFullFilePathForChangeNotify

According to Microsoft's Security Update Guide from December, four CVEs are related to NTFS:

• CVE-2021-43229: Windows NTFS Elevation of Privilege Vulnerability
• CVE-2021-43230: Windows NTFS Elevation of Privilege Vulnerability
• CVE-2021-43231: Windows NTFS Elevation of Privilege Vulnerability
• CVE-2021-43240: NTFS Set Short Name Elevation of Privilege Vulnerability

CVE-2021-43240, seems to be related to NtSetShortNameInfo.

NtfsRenameToPrivateDir, TxfAllocateAndStoreNameForTxLogging and TxAllocateFullFilePathForChangeNotify have all three the same new length check, and seem to be related to CVE-2021-43229, CVE-2021-43230 and CVE-2021-43231, not necessarily in this order. Currently, it is not possible to know which is which, Microsoft is a little bit greedy about these information.

Analysis

In all three CVEs an integer overflow occurs during allocation size computation (directory path length + file name length), leading to a pool-based buffer overflow with the next two memmove of directory path and file name.

Second part - The Path

First try: NtfsRenameToPrivateDir

The path to NtfsRenameToPrivateDir is shown below:

Foremost, to call NtfsCommonSetInformation, just call NtSetInformationFile. Then, to go through NtfsSetLinkInfo and NtfsSetRenameInfo, use respectively FileLinkInformationEx and FileRenameInformationEx as file information class in NtSetInformationFile.

To reach NtfsRemoveSupersededTarget through NtfsSetRenameInfo, it is necessary to set FILE_RENAME_REPLACE_IF_EXISTS and FILE_RENAME_POSIX_SEMANTICS flags. Rename a file with the name of an existing one to access to NtfsRemoveSupersededTarget. For NtfsRenameToPrivateDir, it is a little bit tricky, because the replaced file must be opened by any process.

Unfortunately a length check is done before the call to NtfsRemoveSupersededTarget.

The method with NtfsSetLinkInfo is similar to NtfsSetRenameInfo, only flag's names differs, there meanings still the same. But as well as NtfsSetRenameInfo another check is done before the call to NtfsRemoveSupersededTarget.

Second try: TxfAllocateAndStoreNameForTxLogging

The path to TxfAllocateAndStoreNameForTxLogging is shown below:

Foremost, to call NtfsCommonCreate, just call CreateFile.

The TxfNewFileCreate function is prefixed with Txf which means "Transactional NTFS" and is called when a transacted file is created. TxfAllocateAndStoreNameForTxfLogging is called during the process in order to store the path of the transacted file.

Only two calls are necessary:

• CreateTransaction
• CreateFileTransacted

Third part - PoC It

Vulnerable code of TxfAllocateAndStoreNameForTxLogging is shown below:

In order to trigger the overflow, it is necessary to create a file with an excessive length, more than 0xFFFF bytes (32767 characters).

A problem show up is that a file or directory name cannot be greater than 256 characters - including the NULL character. To solve this one, usage of deep sub folders will be necessary. Weirdly, it is not so easy, even with sub folders created successfully, the sub file cannot be created, certainly due to some checks done earlier.

Using explorer bar it is possible to notice the format used to show the directory path. It is not what I expected, instead of using a "classic" path, explorer use the old-fashioned format of DOS, the 8.3 short format.

Keeping the sub folders creation as before and using short name for sub directories during file creation do the job.

It is important to notice, 16 bytes will be added to the overflowed size, which is the size of the UNICODE_STRING that will represent the final path. It is because the requested memory will contain the UNICODE_STRING followed by the buffer of this UNICODE_STRING.

Method:

• Create sub directories with long name
• Create file with a long name and short names for the directory path

Current conditions:

• The overflow overwrite the equivalent of 64KB
• Allocated memory size is up to 0x20C bytes
• Allocated memory is in paged pool

Fourth part - Leads

An interesting write-up from Synacktiv at SSTIC 2020 could be an idea to dig, by targeting VS Heap.

The CVE-2020-17087 a similar case of exploitation has been presented by PixiePoint Security using the technique mentioned above.