{"id":5027,"date":"2025-01-29T09:33:07","date_gmt":"2025-01-29T08:33:07","guid":{"rendered":"https:\/\/security.humanativaspa.it\/?p=5027"},"modified":"2025-09-23T16:58:34","modified_gmt":"2025-09-23T16:58:34","slug":"cve-2024-49138-windows-clfs-heap-based-buffer-overflow-analysis-part-2","status":"publish","type":"post","link":"https:\/\/hnsecurity.it\/it\/blog\/cve-2024-49138-windows-clfs-heap-based-buffer-overflow-analysis-part-2\/","title":{"rendered":"CVE-2024-49138 Windows CLFS heap-based buffer overflow analysis – Part 2"},"content":{"rendered":"

In the previous article<\/a>, we discussed a vulnerability in the LoadContainerQ()<\/em> function inside clfs.sys. The root cause of the vulnerability was LoadContainerQ() <\/em>using a CLFS_CONTAINER_CONTEXT.pContainer<\/em> without checking if FlushImage()<\/em> invalidated the General Metadata Block.<\/p>\r\n

The previous article mentioned that it was possible to develop another exploit leveraging the patched vulnerability in WriteMetadataBlock()<\/em><\/strong>. The aim of this article is to analyze the vulnerability in WriteMetadataBlock()\u00a0<\/em>and develop another proof of concept exploit.<\/p>\r\n

The Vulnerability Analysis<\/em> section describes the vulnerability and the Exploitation <\/em>section describes how to exploit the vulnerability to obtain arbitrary read\/write in ring 0 and elevate privileges to system. Limitations and Improvements <\/em>highlights some limitations of the existing PoC and provides some hints to improve it, while the Patch Analysis <\/em>section briefly describes the patch applied by Microsoft. Finally, the Detection<\/em> section provides some recommendations to detect exploitation of both vulnerabilities<\/strong>.<\/p>\r\n

As previously, the analysis was conducted on a Windows 11 23H2<\/strong> machine with the following hashes for ntoskrnl.exe and clfs.sys:<\/p>\r\n

PS C:\\Windows\\System32\\drivers> Get-FileHash .\\clfs.sys\r\n\r\nAlgorithm       Hash                                                                   Path\r\n---------       ----                                                                   ----\r\nSHA256          B138C28F72E8510F9612D07D5109D73065CED6CBBF8079A663A1E0601FE0FBAA       C:\\Windows\\System32\\drivers\\c...\r\n\r\n\r\nPS C:\\Windows\\System32\\drivers><\/pre>\r\n
PS C:\\Windows\\System32> Get-FileHash .\\ntoskrnl.exe\r\n\r\nAlgorithm       Hash                                                                   Path\r\n---------       ----                                                                   ----\r\nSHA256          0CE15480462E9CD3F7CBF2D44D2E393CF5674EE1D69A3459ADFA0E913A7A2AEB       C:\\Windows\\System32\\ntoskrnl.exe\r\n\r\n\r\nPS C:\\Windows\\System32><\/pre>\r\n
Note: All code snippets provided here come from reverse engineering and may not be entirely accurate.<\/em><\/p>\r\n
Vulnerability Analysis<\/h2>\r\n
The following screenshot shows the various CLFS_METADATA_BLOCK structures in _CClfsBaseFilePersisted.m_rgBlocks:<\/em><\/p>\r\n
\"\"
General Metadata Block and Shadow in memory and reference counts<\/figcaption><\/figure>\r\n
It is important to notice that the pbImage\u00a0<\/em>of the original block and the one of the shadow block point to the same memory location<\/strong>. However, the reference count of a shadow block is<\/strong> always 0<\/strong> while the reference count of the original block is always higher than 1 and can increase.<\/p>\r\n
In fact, the screenshot shows that the General Metadata Block was loaded in memory at address 0xffffd400ef9a000 and the same address was set also for the corresponding shadow block. However, the reference count of the General Metadata Block is set to 1 while the reference count of General Metadata Block Shadow is set to 0.\u00a0<\/p>\r\n
AddSymbol()<\/h3>\r\n
The CClfsBaseFilePersisted::AddContainer()<\/em> function is responsible for adding a new container and is triggered through the user-space API AddLogContainer()<\/a>:<\/em><\/p>\r\n
__int64 __fastcall CClfsBaseFilePersisted::AddContainer(\r\n        _CClfsBaseFilePersisted *this,\r\n        struct _UNICODE_STRING *container_name,\r\n        ULONGLONG *a3,\r\n        char a4,\r\n        unsigned __int8 arg20,\r\n        unsigned __int8 arg28,\r\n        struct _CLFS_CONTAINER_CONTEXT *a2)\r\n{\r\n[...]
 a2->cidNode.cType = -1;
v11 = ExAcquireResourceExclusiveLite((PERESOURCE)this->m_presImage, 1u);
if ( !CClfsBaseFile::GetBaseLogRecord(this) )
goto LABEL_13;
if ( !RtlNumberOfClearBits(&this->bitmap) )
{
ret = -1072037870;
goto LABEL_15;
}
ExReleaseResourceForThreadLite((PERESOURCE)this->m_presImage, (ERESOURCE_THREAD)KeGetCurrentThread());
ret = CClfsBaseFilePersisted::AddSymbol(
this,
container_name,
&this->m_symtblContainer,
0x30,
&hashsym_container,
(unsigned __int64 *)offset_hashsymcontainer);
ret_1 = ret;
[...]\r\n}<\/pre>\r\n
Internally it calls CClfsBaseFilePersisted::AddSymbol()\u00a0<\/em>to add the container (client and containers are symbols in CLFS) to the General Metadata Block:<\/p>\r\n
__int64 __fastcall CClfsBaseFilePersisted::AddSymbol(\r\n        _CClfsBaseFilePersisted *this,\r\n        struct _UNICODE_STRING *symbol,\r\n        struct _CLFSHASHTBL *hashtable,\r\n        int symsize,\r\n        struct _CLFSHASHSYM **phashsym,\r\n        unsigned __int64 *poffset)\r\n{\r\n[...]\r\n  while ( 1 )\r\n  {\r\n    ret_1 = CClfsBaseFile::FindSymbol(symbol, hashtable, 1, symsize, phashsym);\r\n    if ( ret_1 >= 0 )\r\n    {\r\n      *poffset = *(_DWORD *)phashsym - (unsigned int)CClfsBaseFile::GetBaseLogRecord(this);\r\n      goto ret;\r\n    }\r\n    if ( ret_1 != 0xC0000023 )\r\n      goto ret1;\r\n    container_size = 0LL;\r\n    ret = CClfsContainer::GetContainerSize((_CClfsContainer *)this->pCclfsContainer, &container_size);\r\n    if ( ret < 0 )\r\n      break;\r\n    ExReleaseResourceForThreadLite((PERESOURCE)this->m_presImage, (ERESOURCE_THREAD)KeGetCurrentThread());\r\n    ret_2 = CClfsBaseFilePersisted::ExtendMetadataBlock(this, ClfsMetaBlockGeneral, (unsigned int)container_size >> 1);\r\n    v11 = ExAcquireResourceExclusiveLite((PERESOURCE)this->m_presImage, 1u);\r\n[...]\r\n  return (unsigned int)ret_1;\r\n}<\/pre>\r\n
Notice that it calls CClfsBaseFile::FindSymbol()\u00a0<\/em>to add the symbol. If it fails<\/strong>, it calls ExtendMetadataBlock()<\/em>.<\/p>\r\n
FindSymbol()<\/h3>\r\n
FindSymbol()<\/em> internally calls AllocSymbol():<\/em><\/p>\r\n
__int64 __fastcall CClfsBaseFile::FindSymbol(\r\n        struct _UNICODE_STRING *string,\r\n        struct _CLFSHASHTBL *hashTable,\r\n        char flag,\r\n        int symbolsize,\r\n        struct _CLFSHASHSYM **pphashsym)\r\n{\r\n[...]\r\n  v14 = (_CClfsBaseFilePersisted *)*p_pBaseFile;\r\n  v15 = (_DWORD)poffset - (unsigned int)CClfsBaseFile::GetBaseLogRecord(v14);\r\n  v35 = (symbolsize + 7) & 0xFFFFFFF8;\r\n  v16 = ((__int64 (__fastcall *)(_CClfsBaseFilePersisted *, _QWORD, struct _CLFSHASHSYM **))v14->vftbl_0_00000001C0014000->CClfsBaseFilePersisted::AllocSymbol(ulong,void * *))(\r\n          v14,\r\n          v10 + v35 + 0x30,\r\n          &v36);\r\n if ( v16 < 0 )\r\n  {\r\nLABEL_29:\r\n    *pphashsym = 0LL;\r\n    return (unsigned int)v16;\r\n[...]\r\n}<\/pre>\r\n
AllocSymbol()\u00a0<\/em>fails when cbSymbolZone<\/strong> <\/em>points to a location that is too close to the signatures array<\/strong>. This means that the General Metadata block must be extended:<\/p>\r\n
NTSTATUS __fastcall CClfsBaseFilePersisted::AllocSymbol(_CClfsBaseFilePersisted *this, unsigned int size, void **ppout)\r\n{\r\n[...]\r\n  logBlockHeader = (CLFS_LOG_BLOCK_HEADER *)this_1->m_rgBlocks[ClfsMetaBlockGeneral].pbImage;\r\n  *ppout = 0LL;\r\n  cbSymbolZone = BaseLogRecord->cbSymbolZone;\r\n  if ( (char *)&BaseLogRecord[1] + cbSymbolZone + size_1 > (char *)(&logBlockHeader->MajorVersion\r\n                                                                  + logBlockHeader->SignaturesOffset) )\r\n    return 0xC0000023;\r\n[...]\r\n}<\/pre>\r\n
Therefore, FindSymbol()<\/em> returns the error caused by AllocSymbol()\u00a0<\/em>and causes AddSymbol()\u00a0<\/em>to call CClfsBaseFilePersisted::ExtendMetadataBlock()<\/em>.<\/p>\r\n
ExtendMetadataBlock()<\/h3>\r\n
The ExtendMetadataBlock()\u00a0<\/em>routine first loops over all the blocks starting from blockType, <\/em>that corresponds to ClfsMetaBlockGeneral=2 when called by CClfsBaseFilePersisted::AddSymbol()<\/em>, and calls AcquireMetadataBlock()\u00a0<\/em>on each of them:<\/p>\r\n
__int64 __fastcall CClfsBaseFilePersisted::ExtendMetadataBlock(\r\n        _CClfsBaseFilePersisted *this,\r\n        __int64 blockType,\r\n        __int64 extendedSectors)\r\n{\r\n[...]\r\n  for ( j = blockType_1; j < this->m_cBlocks; j += 2 )\r\n  {\r\n    res = CClfsBaseFile::AcquireMetadataBlock(this, (enum _CLFS_METADATA_BLOCK_TYPE)j);\r\n    res_1 = res;\r\n    if ( res < 0 )\r\n      goto exit1;\r\n  }\r\n  res = CClfsBaseFile::GetControlRecord(this, &controlRecord, 0);\r\n  res_1 = res;\r\n  if ( res < 0 )\r\n    goto exit1;\r\n  controlRecord_1 = controlRecord;\r\n  eExtendState = controlRecord->eExtendState;\r\n  if ( eExtendState )\r\n  {\r\n    v14 = (CClfsBaseFilePersisted *)(unsigned int)(eExtendState - 1);\r\n    if ( (_DWORD)v14 )\r\n    {\r\n      if ( (_DWORD)v14 == 1 )\r\n        goto clfsExtendStateFlusingBlock;\r\n      goto exit;\r\n    }\r\n    goto clfsExtendStateExtendingFsd;\r\n  }\r\n  for ( i = 0; ; ++i )\r\n  {\r\n    i_1 = i;\r\n    if ( i >= this->m_cBlocks )\r\n      break;\r\n    res = CClfsBaseFilePersisted::WriteMetadataBlock(this, (enum _CLFS_METADATA_BLOCK_TYPE)i, 0);\r\n    res_1 = res;\r\n    if ( res < 0 )\r\n      goto exit;\r\n  }\r\n[...]\r\nexit:\r\n  while ( (unsigned int)blockType_1 < j )\r\n  {\r\n    CClfsBaseFile::ReleaseMetadataBlock(this, (enum _CLFS_METADATA_BLOCK_TYPE)blockType_1);\r\n    LODWORD(blockType_1) = blockType_1 + 2;\r\n  }\r\n  if ( res < 0 )\r\n[...]\r\nreturn (unsigned int)res;\r\n}<\/pre>\r\n
AcquireMetadataBlock()<\/em> increases the reference count in m_rgcBlockReferences[blockType] or load the block in memory with ReadMetadataBlock()\u00a0<\/em>and sets the reference count to 1 in m_rgcBlockReferences[blockType]. Notice the AcquireMetadataBlock()<\/em> is not<\/strong> called on shadow blocks<\/strong>.<\/p>\r\n
After that, the function retrieves the CLFS_CONTROL_RECORD,<\/em> calling CClfsBaseFile::GetControlRecord()<\/em>, and checks CLFS_CONTROL_RECORD.eExtendState\u00a0<\/em>field.<\/p>\r\n
If eExtendState\u00a0<\/em>is ClfsExtendStateNone<\/em><\/strong>, i.e., it is 0, it will loop over all the blocks and for each of them call CClfsBaseFilePersisted::WriteMetadataBlock()<\/em>. Notice in this case it calls WriteMetadataBlock()\u00a0<\/em>also on the shadow blocks<\/strong>.<\/p>\r\n
Vulnerable Scenario<\/h3>\r\n
Let’s suppose the following scenario:<\/p>\r\n