CVE-2021-43229 - Passo a passo

Informações públicas

Windows NTFS Vulnerabilidade de Elevação de Privilégio

Diferente de:

• CVE-2021-43230
• CVE-2021-43231

Patch: 14 de Dezembro de 2021

De acordo com @AravGarg3 no Twitter, CVE-2021-43229 parece ser explorável e relacionado a um integer overflow.

Fonte: https://twitter.com/AravGarg3/status/1479447843458863104

Versões do Windows 10

Primeira parte - Diffing

Usando BinDiff com IDA Pro, o resultado da comparação de patches mostra as seguintes alterações:

Três candidatos destacam-se:

• NtfsRenameToPrivateDir
• TxfAllocateAndStoreNameForTxLogging
• TxfAllocateFullFilePathForChangeNotify

De acordo com o Guia de Atualização de Segurança da Microsoft de Dezembro, quatro CVEs estão relacionados ao 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 parece estar relacionado a NtSetShortNameInfo.

NtfsRenameToPrivateDir, TxfAllocateAndStoreNameForTxLogging e TxAllocateFullFilePathForChangeNotify têm todos a mesma nova verificação de comprimento, e parecem estar relacionados a CVE-2021-43229, CVE-2021-43230 e CVE-2021-43231, não necessariamente nessa ordem. Atualmente, não é possível saber qual é qual, a Microsoft é um pouco avarenta com essas informações.

Análise

Em todos os três CVEs ocorre um integer overflow durante o cálculo do tamanho da alocação (comprimento do caminho do diretório + comprimento do nome do arquivo), levando a um estouro de buffer baseado em pool com os dois memmove seguintes do caminho do diretório e do nome do arquivo.

Segunda parte - O Caminho

Primeira tentativa: NtfsRenameToPrivateDir

O caminho para NtfsRenameToPrivateDir é mostrado abaixo:

NtfsCommonSetInformation
       |__________________
       |                  |
       v                  v
NtfsSetLinkInfo   NtfsSetRenameInfo
       |__________________|
       |
       v
NtfsRemoveSupersededTarget
       |
       v
NtfsRenameToPrivateDir

Antes de mais nada, para chamar NtfsCommonSetInformation, basta chamar NtSetInformationFile. Em seguida, para passar por NtfsSetLinkInfo e NtfsSetRenameInfo, use respectivamente FileLinkInformationEx e FileRenameInformationEx como classe de informações de arquivo em NtSetInformationFile.

Para alcançar NtfsRemoveSupersededTarget através de NtfsSetRenameInfo, é necessário definir as flags FILE_RENAME_REPLACE_IF_EXISTS e FILE_RENAME_POSIX_SEMANTICS. Renomeie um arquivo com o nome de um existente para acessar NtfsRemoveSupersededTarget. Para NtfsRenameToPrivateDir, é um pouco complicado, porque o arquivo substituído deve estar aberto por algum processo.

Infelizmente, uma verificação de comprimento é feita antes da chamada a NtfsRemoveSupersededTarget.

O método com NtfsSetLinkInfo é semelhante ao NtfsSetRenameInfo, apenas os nomes das flags diferem, seus significados permanecem os mesmos. Mas, assim como em NtfsSetRenameInfo, outra verificação é feita antes da chamada a NtfsRemoveSupersededTarget.

Segunda tentativa: TxfAllocateAndStoreNameForTxLogging

O caminho para TxfAllocateAndStoreNameForTxLogging é mostrado abaixo:

NtfsCommonCreate
      |
      v
NtfsCreateNewFile
      |
      v
TxfNewFileCreate
      |
      v
TxfAllocateAndStoreNameForTxfLogging

Antes de mais nada, para chamar NtfsCommonCreate, basta chamar CreateFile.

A função TxfNewFileCreate é prefixada com Txf, que significa "Transactional NTFS" (NTFS Transacional) e é chamada quando um arquivo transacional é criado. TxfAllocateAndStoreNameForTxfLogging é chamada durante o processo para armazenar o caminho do arquivo transacional.

Apenas duas chamadas são necessárias:

• CreateTransaction
• CreateFileTransacted

Terceira parte - PoC

O código vulnerável de TxfAllocateAndStoreNameForTxLogging é mostrado abaixo:

...
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
...

Para acionar o estouro, é necessário criar um arquivo com um comprimento excessivo, mais de 0xFFFF bytes (32767 caracteres).

Um problema que surge é que um nome de arquivo ou diretório não pode ter mais de 256 caracteres - incluindo o caractere NULL. Para resolver isso, será necessário o uso de subpastas profundas. Estranhamente, não é tão fácil, mesmo com subpastas criadas com sucesso, o subarquivo não pode ser criado, certamente devido a algumas verificações feitas anteriormente.

Usando a barra do explorer, é possível notar o formato usado para mostrar o caminho do diretório. Não é o que eu esperava, em vez de usar um caminho "clássico", o explorer usa o formato antiquado do DOS, o formato curto 8.3.

Manter a criação de subpastas como antes e usar o nome curto para os subdiretórios durante a criação do arquivo resolve o problema.

É importante notar que 16 bytes serão adicionados ao tamanho estourado, que é o tamanho da UNICODE_STRING que representará o caminho final. Isso porque a memória solicitada conterá a UNICODE_STRING seguida pelo buffer dessa UNICODE_STRING.

Método:

• Criar subdiretórios com nome longo
• Criar arquivo com um nome longo e nomes curtos para o caminho do diretório

Condições atuais:

• O estouro sobrescreve o equivalente a 64KB
• O tamanho da memória alocada é de até 0x20C bytes
• A memória alocada está no pool paginado

Quarta parte - Pistas

Um write-up interessante da Synacktiv no SSTIC 2020 poderia ser uma ideia para investigar, visando o VS Heap.

O CVE-2020-17087, um caso semelhante de exploração, foi apresentado pela PixiePoint Security usando a técnica mencionada acima.