So, I was looking for vulnerabilities on the MSRC Vulnerability portal , then I thought to try this CVE-2024-38041 . It was a Information Disclosure Vulnerability. More Information Provided by Microsoft is that an attacker can use this bug to leak one byte of kernel memory. This Bug was found by Le Tran Hai Tung .
I was Patch Diffing this CVE and thought that there is Bug left by windows developers in a function. LOL ,It wasn't My Bad.
Patch Diffing
This Bug was patched in July patch Tuesday on 9 July 2024. I am testing this on windows 11 22H2 machine. I got the Binaries from Winbindex. Select the Signing Date option for better search.
So, we will look for binaries signed approx. in July or June.
Here, is the two versions of ntoskrnl.exe the recent patched version and one update back. You can confirm that clicking at the show Button an Checking the release date of the executable.
Load Both Binaries in Ida Pro and let Ida download the Symbols for ntoskrnl.exe and once it has analyzed the Binary, use Binexport to export it in .binexport format.
FINDING BUG
I am using BinDiff to diff the Patch. BinExport is also installed after installing BinDiff. Open Bindiff and load these two binexport files of both patched and unpatched version.
After Bindiff has Analyzed all the functions, select the matched functions and arrange the Similarity. You will get Something like this:
Here You can see that there are changes in only 5 functions . You check the Graph View of these functions But this function CmpRemoveCellFromIndex has small graph view which is easy to analyse and looks like some checks has been added .
So, a cmp instruction has been added before a memmove call , looks life a check is added to prevent copy kernel information to attacker. Lets Look it in Ida.
This is the 1 Byte Information Disclosure Bug CVE-2024-38041.
Now, These three functions CmCheckRegistry, CmpRemoveCellFromIndex, CmpRemoveSubkeyCellNoCellRef are related to each other .Actually these are called by CmCheckRegistry function which is related to windows registry API.
Recently Google Project zero has submitted 39 bug reports in the windows registry, you can read the blog here . Due to the legacy code used in windows registry , it has a lot of bugs.
This function CmpRemoveSubKeyCellNoCellRef has reference to function CmpRemoveCellfromIndex. and this function has reference to CmCheckRegistry2 which has reference to CmCheckregistry which is called by function cmpCreateHive.
The CmpCreateHive has lot of references but all of these references are related to function CmRestoreKey.
So, To a create a POC for this CVE we can use some windows registry API like this RegRestorekeyA because the bug is in the restoring the registry Key.
POC: To be Continued.
Further Analysis.
So, Two more functions left that are patched in this CVE. So the first one MivalidateSectionCreate . This function has used a lot by malwares so Microsoft's plan is to kill that so i guess that' the reason of the patch of this function . You can read more about this here.
Last Function is NtQueryMultipleValueKey, which is a windows registry API . It Retrieves values from Multiple Value Key. Comparing the Patched and Unpatched version in Ida.
In the Patched version , they have just removed this function
Feature_Servicing_PostQueryMultipleValueKey__private_IsEnabledDeviceUsage(). This function just check that the caller is called from User mode or Kernel mode.
My Assumption:
While analysing this function I thought that there is no check on the user supplied input length so it may leaks kernel information.
It does only basic check on the user supplied length and set it to the length . So, this function CmpBounceContextCopyDataTocallerBuffer will copy that length of buffer to usermode and leaks kernel memory.
So, I Wrote this POC to test this :
#include <Windows.h>
#include <stdio.h>
typedef struct _UNICODE_STRING {
USHORT Length;
USHORT MaximumLength;
PWSTR Buffer;
} UNICODE_STRING, * PUNICODE_STRING;
typedef struct _KEY_VALUE_ENTRY {
PUNICODE_STRING ValueName;
ULONG DataLength;
ULONG DataOffset;
ULONG Type;
} KEY_VALUE_ENTRY, * PKEY_VALUE_ENTRY;
//NtQueryMultipleValueKey
typedef NTSTATUS(WINAPI* NtQueryMultipleValueKey_t)(
HANDLE KeyHandle,
PKEY_VALUE_ENTRY ValueEntries,
ULONG EntryCount,
PVOID ValueBuffer,
PULONG Bufferlength,
PULONG RequiredBufferLength
);
typedef void(WINAPI* RtlInitUnicodeString_t)(
PUNICODE_STRING DestinationString,
PCWSTR SourceString
);
NtQueryMultipleValueKey_t NtQueryMultipleValueKey;
RtlInitUnicodeString_t RtlInitUnicodeString;
int main()
{
HMODULE hntdll = NULL;
hntdll = LoadLibraryA("ntdll.dll");
if (!hntdll)
{
printf("[-] Failed to open handle to ntdll.dll\n : 0x%08x", GetLastError());
exit(EXIT_FAILURE);
}
NtQueryMultipleValueKey = (NtQueryMultipleValueKey_t)GetProcAddress(hntdll, "NtQueryMultipleValueKey");
RtlInitUnicodeString = (RtlInitUnicodeString_t)GetProcAddress(hntdll, "RtlInitUnicodeString");
printf("[+] NtQueryMultipleValueKey Address: 0x%p\n", NtQueryMultipleValueKey);
printf("[+] RtlInitUnicodeString Address: 0x%p\n", RtlInitUnicodeString);
// open key to \HKEY_CURRENT_USER\Software\Testdir
LSTATUS lresult;
HKEY hTestKey = 0;
lresult = RegOpenKeyEx(HKEY_CURRENT_USER,
TEXT("Software\\Testdir"),
0,
KEY_QUERY_VALUE,
&hTestKey);
if (lresult != ERROR_SUCCESS)
{
if (lresult == ERROR_FILE_NOT_FOUND)
{
printf("Key not found.\n");
exit(EXIT_FAILURE);
}
else {
printf("Error Opening Key.\n");
exit(EXIT_FAILURE);
}
}
printf("[+] Handle to key Software\\Testdir : 0x%08x\n", (ULONG)hTestKey);
PUNICODE_STRING Value1 = (PUNICODE_STRING)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(UNICODE_STRING));
PUNICODE_STRING Value2 = (PUNICODE_STRING)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(UNICODE_STRING));
RtlInitUnicodeString(Value1, L"lpe");
RtlInitUnicodeString(Value2, L"test");
//array of KEY_VALUE_ENTRY structure to hold the data value.
KEY_VALUE_ENTRY ValueEntries[2] = { 0 };
ValueEntries[0].ValueName = Value1;
ValueEntries[0].DataLength = 100;
ValueEntries[0].DataOffset = 0;
ValueEntries[0].Type = REG_SZ;
ValueEntries[1].ValueName = Value2;
ValueEntries[1].DataLength = 100;
ValueEntries[1].DataOffset = 0;
ValueEntries[1].Type = REG_SZ;
/*PKEY_VALUE_ENTRY ValueEntries;
if (ValueEntries == NULL) {
}*/
//printf("[-] ValueEntries.ValuName : %s\n", ValueEntries.ValueName);
char ValueBuffer[100] = { 0 };
ULONG BufferLength = 101;
OutputDebugString(L"ValueBuffer Address: 0x%p\n", ValueBuffer);
NTSTATUS result = 0;
result = NtQueryMultipleValueKey(hTestKey,
ValueEntries,
2,
&ValueBuffer,
&BufferLength,
NULL);
printf("[-] Return code : 0x%08x\n", result);
for (int i = 0; i < 100; i++)
{
printf("ValueBuffer [%d]: 0x%08x\n", i, ValueBuffer[i]);
}
return EXIT_SUCCESS;
}
But it doesn't leaks any memory , then after some debugging in WinDbg . I tried that few weeks ago so I haven't taken any Screenshot to show the length change in WinDbg . I found that there is function between this which is changing the length .
This function calculates the length required to store the multi-value Key and changes the length according to that.
LOL, There is no Bug Here , But It was worth trying and learning new debugging ways and experience.
Thanks