Windows NTFS
Elevation of Privilege Vulnerability
Unique from:
- CVE-2021-43230
- CVE-2021-43231
Patch: Dec 14, 2021
According to @AravGarg3
on Twitter
, CVE-2021-43229
seems to be exploitable and related to an integer overflow
.
Source: https://twitter.com/AravGarg3/status/1479447843458863104
Minor versions of Windows 10 | Release dates |
---|---|
1387 | 11/22/2021 |
1415 | 12/14/2021 |
Using BinDiff
with IDA Pro
, patch diffing result with the following changes:
Simi | Conf | Function | Info | |
---|---|---|---|---|
NOK | 0.98 | 0.99 | NtfsCommonSetInformation$fin$0 | Jump modifications |
0.97 | 0.99 | NtSetShortNameInfo | ||
0.96 | 0.99 | NtfsUpdateSecurity | ||
NOK | 0.91 | 0.94 | NtfsRenameToPrivateDir$fin$1 | Jump modifications |
0.89 | 0.98 | NtfsInitializeFileInDirectory | ||
OK | 0.88 | 0.95 | TxfAllocateAndStoreNameForTxLogging | Length check |
OK | 0.87 | 0.93 | NtfsRenameToPrivateDir | Length check |
OK | 0.81 | 0.95 | TxfAllocateFullFilePathForChangeNotify | Length check |
0.76 | 0.94 | NtfsCommonSetInformation |
Three candidates come to the top:
- NtfsRenameToPrivateDir
- TxfAllocateAndStoreNameForTxLogging
- TxfAllocateFullFilePathForChangeNotify
According to Microsoft
's Security Update Guide
from December, four CVE
s 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.
In all three CVE
s 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.
The path to NtfsRenameToPrivateDir
is shown below:
NtfsCommonSetInformation
|__________________
| |
v v
NtfsSetLinkInfo NtfsSetRenameInfo
|__________________|
|
v
NtfsRemoveSupersededTarget
|
v
NtfsRenameToPrivateDir
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
.
The path to TxfAllocateAndStoreNameForTxLogging
is shown below:
NtfsCommonCreate
|
v
NtfsCreateNewFile
|
v
TxfNewFileCreate
|
v
TxfAllocateAndStoreNameForTxfLogging
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
Vulnerable code of TxfAllocateAndStoreNameForTxLogging
is shown below:
...
and di, 2
add di, [rsi+UNICODE_STRING.Length] ; File name
add di, [rsp+68h+RelativeNormalizedDirectoryPath.Length] ; OVERFLOW HERE
cmp [rsp+68h+arg_20], r12b
jnz loc_16592C
movzx edx, di
add rdx, size UNICODE_STRING ; NumberOfBytes
mov ecx, cs:PoolType
or ecx, 10h ; PoolType
mov r8d, 'afxT' ; Tag
call cs:__imp_ExAllocatePooliWthTag
...
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
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.