CVE-2023-21766 analysis

Patchdiffing another CVE and some thoughts

Introduction

Had some time this weekend and felt like analysing a CVE, so I went to CVE Details to look for some new Windows 11 CVEs.

Right on top are a pair of CVEs affecting the Windows Overlay Filter (wof.sys).

CVE-2023-21766 leads to information disclosure through a race condition, while CVE-2023-21767 achieves EOP.

I chose to focus on the information disclosure bug since full EOP exploits tend to require much effort. Also, with the soon removal of NtQuerySystemInformation() like APIs from Medium IL, information disclosure bugs are getting more valuable.

Spoiler: I did not manage to complete the poc, so this is more of a diary.

Update: I did manage to poc it after consulting the researcher who discovered this bug, @k0shl .
Check the Update section at the end.

Patchdiff

With a lack of public information regarding the bug, we will have to diff the patch to understand the bug.

Microsoft’s official patch is released on Jan 10, 2023 as part of security update KB5022289.
You can download the update and patchdiff it that way, but my go-to method now is to use Winbindex.

Winbindex is a collection of Windows system binaries across updates.
We can easily find wof.sys binaries before and after the patch.

To learn patchdiffing using BinDiff and IDA I suggest watching Modern Binary/Patch Diffing! by Off By One Security.

Comparing between the functions, we see only 2 functions with changes. WimCbEnumOverlay and WimFSFInitializeOffsetTable.

WimCbEnumOverlay

The main change is adding a call to hold a FastMutex before proceeding.

WimFSFInitializeOffsetTable

The main change is checking if a field is indeed smaller than another before proceeding.

At this point, I have a rough idea that the information disclosure probably exists due to the lack of locking in WimCbEnumOverlay, and the EOP happens due to out of bounds operations in WimFSFInitializeOffsetTable.

Woof Woof?

Wait hold on… wtf does wof.sys even do, what’s FSF and Wim? So many acronyms!

This is when we do reconnaissance, similar to how pentesters map assets before actually attacking.
There’s no better place to start than MSDN Documentation.

A quick search reveals that Wim stands for Windows Image, which is a backup format to store a set of files, up to an entire partition.

We can inform the OS that we have backed up a partition using Wim by adding a Wim Overlay to a volume. This along with overlays from other providers are then managed by the Windows Overlay Filter, wof.sys.

Going a few pages down we find documentation for the WIM_PROVIDER_ADD_OVERLAY_INPUT structure, which very kindly points us to a few FSCTL_* APIs.

They sound awfully like the functions residing in wof.sys:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
__int64 __fastcall WimFSFInitializeProvider(_WORD *a1, __int64 a2)
{
  memset(a1, 0, 0x1A8ui64);
  *a1 = 257;
  *((_QWORD *)a1 + 5) = WimCbAddOverlay;
  *((_BYTE *)a1 + 2) = 1;
  *((_QWORD *)a1 + 8) = WimCbUpdateOverlay;
  *((_QWORD *)a1 + 7) = WimCbSuspendOverlay;
  *((_QWORD *)a1 + 6) = WimCbRemoveOverlay;
  *((_QWORD *)a1 + 9) = WimCbEnumOverlay;
  *((_QWORD *)a1 + 12) = WimCbCleanupStreamContext;
  *((_QWORD *)a1 + 13) = WimCbCleanupVolumeContext;

  ...

  *((_DWORD *)a1 + 1) = 96;
  *((_DWORD *)a1 + 2) = 64;
  *((_DWORD *)a1 + 4) = 80;
  *((_DWORD *)a1 + 6) = 6;
  WimSqmInitialize((const void **)a2);
  return 0i64;
}

Again I’m making a guess that invoking one of these FSCTL_* operations will eventually lead to the Wim functions processing our data, in the event that we use Wim as a backing provider.

Based on the docs I made some wrapper functions to interact with Wim.

Here’s an example to interact with WimEnumCbOverlay:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
static NTSTATUS EnumOverlay(HANDLE hVolume, WIM_PROVIDER_OVERLAY_ENTRY *outBuf, ULONG outSize)
{
    IO_STATUS_BLOCK                 isb = { 0 };
    WOF_EXTERNAL_INFO               info = { 0 };
    NTSTATUS                        status;

    info.Provider = WOF_CURRENT_VERSION;
    info.Version = WOF_PROVIDER_WIM;

    status = NtFsControlFile(
        hVolume, 
        NULL, 
        NULL, 
        NULL, 
        &isb, 
        FSCTL_ENUM_OVERLAY, 
        &info, 
        sizeof(WOF_EXTERNAL_INFO), 
        outBuf, 
        outSize
    );

    // printf("[+] EnumOverlay Status: 0x%08X\n", status);
    return status;
}

Again, all of these are public information available in MSDN Docs. It’s a pure goldmine.

This call will inevitably fail, because we have yet to add any overlays.

Adding Overlay

First we create 2 partitions, E and F.

Then we make some a dummy directory on partition E and invoke the native Dism tool to backup the entire partition into a Wim.

1
Dism /Capture-Image /ImageFile:C:\Users\User\Desktop\mywim.wim /CaptureDir:E:\ /Name:"anything"

Now we wrap the FSCTL_ADD_OVERLAY code like shown above:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
static NTSTATUS AddOverlay(_In_ HANDLE hVolume, _In_ LPCWSTR wimPath, _Out_ PLARGE_INTEGER dataSrc)
{
    IO_STATUS_BLOCK                 isb = { 0 };
    WOF_EXTERNAL_INFO               *info = NULL;
    WIM_PROVIDER_ADD_OVERLAY_INPUT  *overlayInput = NULL;
    NTSTATUS                        status;
    SIZE_T                          inputSize = 0;
    WCHAR                           *fileName = NULL;

    inputSize = sizeof(WOF_EXTERNAL_INFO) + \
        sizeof(WIM_PROVIDER_ADD_OVERLAY_INPUT) + (wcslen(wimPath) + 1) * 2;

    info = zalloc(inputSize);
    if (!info) {
        err("AddOverlay::HeapAlloc", GetLastError());
        return STATUS_HEAP_CORRUPTION; // fuck it
    }
    overlayInput = (WIM_PROVIDER_ADD_OVERLAY_INPUT *)((ULONG_PTR)info + sizeof(WOF_EXTERNAL_INFO));
    fileName = (WCHAR *)((ULONG_PTR)overlayInput + sizeof(WIM_PROVIDER_ADD_OVERLAY_INPUT));

    info->Version = WOF_CURRENT_VERSION;
    info->Provider = WOF_PROVIDER_WIM;

    overlayInput->WimType = WIM_BOOT_NOT_OS_WIM;
    overlayInput->WimIndex = 0x1;
    overlayInput->WimFileNameOffset = sizeof(WIM_PROVIDER_ADD_OVERLAY_INPUT);
    overlayInput->WimFileNameLength = wcslen(wimPath) * 2;

    wcscpy_s(fileName, wcslen(wimPath) + 1, wimPath);

    status = NtFsControlFile(
        hVolume,
        NULL,
        NULL,
        NULL,
        &isb,
        FSCTL_ADD_OVERLAY,
        info,
        inputSize,
        dataSrc,
        sizeof(LARGE_INTEGER)
    );
    if (!NT_SUCCESS(status))
        err("AddOverlay::NtFsControlFile", status);

    zfree(info);

    // printf("[+] AddOverlay Status 0x%08X\n", status);
    return status;
}

The path must be a full path, like:

1
\??\C:\Users\User\Desktop\mywim.wim

If we run the code now we’ll get a 0xC00000BB error:

1
2
3
4
5
6
7
C:\Users\User\Desktop>.\exp.exe
[+] Resolving Symbols
[+] Symbols Resolved
[+] Acquiring Handle
[+] Handle Acquired
[-] AddOverlay::NtFsControlFile : 0xC00000BB
[+] AddOverlay Status 0xC00000BB

which means The request is not supported.

I’m not sure if this is the correct way to use Wim(it surely isn’t), but I followed the code flow in windbg and ida to find the offending function:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
NTSTATUS __fastcall WimFSFValidateWim(struct _FLT_INSTANCE *flt_instance, _FILE_OBJECT *fileobj, char *buf, _QWORD *a4)
{
  unsigned int v6; // ebx
  NTSTATUS result; // eax

  ...

        if ( (buf[16] & 0x38) != 0 )
        {
          if ( (HIDWORD(WPP_GLOBAL_Control->Timer) & 8) != 0 && BYTE1(WPP_GLOBAL_Control->Timer) >= 2u )
            WPP_SF_(WPP_GLOBAL_Control->AttachedDevice, 19i64, &WPP_671cefaefadf32987991538ffedf2d72_Traceguids);
          v6 = 0xC00000BB;
        }

  ...

  return result;
}

To bypass the check just null out byte 16 in the wim file.

After fix:

1
2
3
4
5
6
C:\Users\User\Desktop>.\exp.exe
[+] Resolving Symbols
[+] Symbols Resolved
[+] Acquiring Handle
[+] Handle Acquired
[+] AddOverlay Status 0x00000000

Using native fsutil we can confirm that the overlay is added:

1
2
3
4
5
C:\Users\User\Desktop>fsutil wim enumWims F:
   0 {28569C0B-5DB0-42A9-AD01-8575D276E9A5} 00000000 C:\Users\User\Desktop\mywim.wim:1
Wim State:      SUSPENDED

Objects enumerated: 1

And we can dump it out using the EnumOverlay function written above:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
C:\Users\User\Desktop>.\exp.exe
[+] Resolving Symbols
[+] Symbols Resolved
[+] Acquiring Handle
[+] Handle Acquired
[+] AddOverlay Status 0x00000000

---------- Dumping Overlay Info ----------

Data Src ID: 0x00000000
GUID First Part: 0x28569c0b
GUID Second Part: 0x1e1eaff5448
FileName Offset: 30
FileName: \??\C:\Users\User\Desktop\mywim.wim
Wim Index: 1
Wim Type: 0
Flags: 2

-------------- End Of Dump ---------------

Sweet!

Reversing WimCb*

Up to this point we didn’t really need to touch ida, other than to fix that weird verification.
Unfortunately in order to truly understand the bug, reversing part of wof.sys is inevitable.
Honestly with pdb and no protections I’m not complaining.

Initially you get something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
__int64 __fastcall WimCbEnumOverlay(__int64 a1, __int64 a2, __int64 a3, __int64 a4, unsigned int a5, unsigned int *a6)
{
  int v8; // ebx
  unsigned int v9; // er15
  __int64 v10; // r14
  __int64 i; // rsi
  unsigned int v12; // ecx
  __int64 result; // rax

  v8 = 0;
  v9 = 0;
  v10 = 0i64;
  ExAcquireFastMutexUnsafe((PFAST_MUTEX)(a1 - (unsigned int)dword_1C001927C));
  for ( i = *(_QWORD *)(a1 + 16); i != a1 + 8; i = *(_QWORD *)(i + 8) )
  {
    if ( (*(_DWORD *)(i + 40) & 6) == 0 )
    {
      ExReleaseFastMutexUnsafe((PFAST_MUTEX)(a1 - (unsigned int)dword_1C001927C));
      ++v8;
      v12 = (*(unsigned __int16 *)(i + 56) + 57) & 0xFFFFFFF8;
      v9 += v12;
      if ( v9 <= a5 )
      {
        v10 = a4;
        a4 += v12;
        *(_OWORD *)v10 = 0i64;
        *(_OWORD *)(v10 + 16) = 0i64;
        *(_OWORD *)(v10 + 32) = 0i64;
        *(_DWORD *)v10 = v12;
        *(_QWORD *)(v10 + 8) = *(_QWORD *)(i + 88);
        *(_DWORD *)(v10 + 40) = *(_DWORD *)(i + 52);
        *(_DWORD *)(v10 + 36) = *(_DWORD *)(i + 48);
        *(_DWORD *)(v10 + 32) = 48;
        memmove((void *)(v10 + 48), *(const void **)(i + 64), *(unsigned __int16 *)(i + 56));
        *(_WORD *)(v10 + 2 * ((unsigned __int64)*(unsigned __int16 *)(i + 56) >> 1) + 48) = 0;
        *(_OWORD *)(v10 + 16) = *(_OWORD *)(i + 72);
        WimFSFGetOverlayFlags(i, v10 + 44);
      }
      ExAcquireFastMutexUnsafe((PFAST_MUTEX)(a1 - (unsigned int)dword_1C001927C));
    }
  }
  ExReleaseFastMutexUnsafe((PFAST_MUTEX)(a1 - (unsigned int)dword_1C001927C));
  if ( v8 )
  {
    result = a5 < v9 ? 0xC0000023 : 0;
    if ( v9 <= a5 && v10 )
      *(_DWORD *)v10 = 0;
    *a6 = v9;
  }
  else
  {
    if ( (HIDWORD(WPP_GLOBAL_Control->Timer) & 8) != 0 && BYTE1(WPP_GLOBAL_Control->Timer) >= 4u )
      WPP_SF_Z(
        WPP_GLOBAL_Control->AttachedDevice,
        18i64,
        &WPP_2ae1970b699a3a98153f0b415e140057_Traceguids,
        a1 - (unsigned int)dword_1C001927C + 64);
    result = 3221225487i64;
  }
  return result;
}

By experience anything with a +16 or +8 in a windows driver for loop is PROBABLY a LIST_ENTRY.

We can also see some global offset being subtracted from a1 to point to a mutex.
a1 is therefore probably a global structure storing the head of linked lists and mutexes.

v10 is being indexed and written to? Probably a struct to return back for usermode consumption.

After cleaning up:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
__int64 __fastcall WimCbEnumOverlay(GlobalStruct *global, __int64 a2, __int64 a3, WIM_PROVIDER_OVERLAY_ENTRY *nextBuf, unsigned int outbuf_sz, unsigned int *outbytes_written)
{
  int counter; // ebx
  unsigned int totalSize; // er15
  DataToUser *curBuf; // r14
  PerOverlayEntry *i; // rsi
  unsigned int curBufSize; // ecx
  __int64 result; // rax

  counter = 0;
  totalSize = 0;
  curBuf = 0i64;
  ExAcquireFastMutexUnsafe((PFAST_MUTEX)((char *)global - (unsigned int)const_0xb0));
  for ( i = (PerOverlayEntry *)global->embedded.entry.Blink; i != &global->embedded; i = (PerOverlayEntry *)i->entry.Blink )
  {
    if ( (i->flag & 6) == 0 )                   // INUSE bit
    {
      ExReleaseFastMutexUnsafe((PFAST_MUTEX)((char *)global - (unsigned int)const_0xb0));
      ++counter;
      curBufSize = (i->filenameLength + 0x39) & 0xFFFFFFF8;
      totalSize += curBufSize;
      if ( totalSize <= outbuf_sz )
      {
        curBuf = (DataToUser *)nextBuf;
        nextBuf = (WIM_PROVIDER_OVERLAY_ENTRY *)((char *)nextBuf + curBufSize);
        *(_OWORD *)&curBuf->overlayEntry.NextEntryOffset = 0i64;
        curBuf->overlayEntry.WimGuid = 0i64;
        *(_OWORD *)&curBuf->overlayEntry.WimFileNameOffset = 0i64;
        curBuf->overlayEntry.NextEntryOffset = curBufSize;
        curBuf->overlayEntry.DataSourceId.QuadPart = i->dataSrc.QuadPart;
        curBuf->overlayEntry.WimIndex = i->index;
        curBuf->overlayEntry.WimType = i->type;
        curBuf->overlayEntry.WimFileNameOffset = 0x30;
        memmove(curBuf->data, i->fileNamePtr, i->filenameLength);// prob arb read if we can control fileNamePtr
        curBuf->data[(unsigned __int64)i->filenameLength >> 1] = 0;// set terminating null for unicode string, possible arb zeroing if we can control filenameLength
        curBuf->overlayEntry.WimGuid = i->guid;
        WimFSFGetOverlayFlags(i, &curBuf->overlayEntry.Flags);
      }
      ExAcquireFastMutexUnsafe((PFAST_MUTEX)((char *)global - (unsigned int)const_0xb0));
    }
  }
  ExReleaseFastMutexUnsafe((PFAST_MUTEX)((char *)global - (unsigned int)const_0xb0));
  if ( counter )
  {
    result = outbuf_sz < totalSize ? (unsigned int)STATUS_BUFFER_TOO_SMALL : 0;
    if ( totalSize <= outbuf_sz && curBuf )
      curBuf->overlayEntry.NextEntryOffset = 0;
    *outbytes_written = totalSize;
  }
  else
  {
    result = 0xC000000Fi64;
  }
  return result;
}

WimCbEnumOverlay iterates through a linked list looking for non-deleted overlay entries, then copying to usermode.

Knowing it’s a race condition, we can start thinking of possible exploitation scenarios.

  • What if we remove the entire overlay while the enum is copying? Can we get a UAF style control over unicode pointer?

  • Can we update the path to a different length for OOB read?

For the first hypothesis, turns out WimCbRemoveOverlay does not actually release any structures.
As far as we need to be concerned, it just sets a flag to indicate that the entry is not active and should not be parsed by WimCbEnumOverlay.

As for the second hypothesis, we’ll have to look at WimCbUpdateOverlay:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
__int64 __fastcall WimCbUpdateOverlay(int a1, GlobalStruct *a2, WIM_PROVIDER_UPDATE_OVERLAY_INPUT *overlayInput, unsigned int fileNameLengthAfterBuffer)
{
  PFAST_MUTEX fastmtx; // r14
  ULONG FileNameLength; // eax
  __int64 FileNameOffset; // rcx
  int v10; // eax
  unsigned int v11; // ebx
  __int64 result; // rax
  const void **v13; // rbx
  int v14; // esi
  int v15; // er8
  PerOverlayEntry *entryToUpdate; // rdi
  WCHAR *NewAllocation; // rax
  WCHAR *v18; // r14
  PerOverlayEntry *OldEntry; // rbx
  WCHAR *OldEntryFileName; // rcx
  PerOverlayEntry *EntryToUpdate; // [rsp+40h] [rbp-41h] BYREF
  PFLT_CONTEXT Context; // [rsp+48h] [rbp-39h] BYREF
  void *Src[2]; // [rsp+50h] [rbp-31h] BYREF
  UNICODE_STRING fileNameUnicodeString; // [rsp+60h] [rbp-21h] BYREF
  PVOID FltObject; // [rsp+70h] [rbp-11h] BYREF
  UNICODE_STRING newUnicodeString; // [rsp+78h] [rbp-9h]
  __int64 a5[2]; // [rsp+88h] [rbp+7h] BYREF

  fastmtx = (PFAST_MUTEX)((char *)a2 - (unsigned int)const_0xb0);
  EntryToUpdate = 0i64;
  fileNameUnicodeString = 0i64;
  if ( fileNameLengthAfterBuffer < 0x10 )       // check if enough space provided after buffer
    return 0xC000000Di64;
  FileNameLength = overlayInput->WimFileNameLength;
  if ( FileNameLength >= 0xFFFF )
    return 0xC000000Di64;
  if ( (FileNameLength & 1) != 0 )
    return 0xC000000Di64;                       // even number length
  FileNameOffset = overlayInput->WimFileNameOffset;
  if ( (unsigned int)FileNameOffset > fileNameLengthAfterBuffer
    || FileNameLength + (unsigned int)FileNameOffset < (unsigned int)FileNameOffset
    || FileNameLength + (unsigned int)FileNameOffset > fileNameLengthAfterBuffer )
  {
    return 0xC000000Di64;
  }
  fileNameUnicodeString.Length = overlayInput->WimFileNameLength;
  fileNameUnicodeString.MaximumLength = FileNameLength;
  fileNameUnicodeString.Buffer = (PWSTR)((char *)overlayInput + FileNameOffset);
  v10 = WofGetAttachVolumeFromPathName(&fileNameUnicodeString, (struct _UNICODE_STRING *)Src, &FltObject, &Context);
  v11 = v10;
  if ( v10 >= 0 )
  {

    ...

    if ( ...
      || (v14 = WimFSFFindOverlayByDataSource(a2, overlayInput->DataSourceId, &EntryToUpdate), v14 < 0) )
    {
      ...
    }
    else
    {
      entryToUpdate = EntryToUpdate;
      newUnicodeString = 0i64;
      if ( (EntryToUpdate->flag & 5) != 0 )
      {
        newUnicodeString.Length = LOWORD(Src[0]) + *((_WORD *)v13 + 32);
        newUnicodeString.MaximumLength = newUnicodeString.Length;
        NewAllocation = (WCHAR *)ExAllocatePoolWithTag(PagedPool, newUnicodeString.Length, 'fcpw');
        newUnicodeString.Buffer = NewAllocation;
        v18 = NewAllocation;
        if ( NewAllocation )
        {
          memmove(NewAllocation, v13[9], *((unsigned __int16 *)v13 + 32));
          memmove((char *)v18 + *((unsigned __int16 *)v13 + 32), Src[1], LOWORD(Src[0]));
          ExAcquireFastMutexUnsafe(&entryToUpdate->mutex); // Proper Locking
          if ( entryToUpdate->shitty )
          {
            ExReleaseFastMutexUnsafe(&entryToUpdate->mutex);
            ExFreePoolWithTag(v18, 0);
          }
          else
          {
            _InterlockedOr((volatile signed __int32 *)&entryToUpdate->flag, 1u);
            _InterlockedAnd((volatile signed __int32 *)&entryToUpdate->flag, 0xFFFFFFEB);
            OldEntry = EntryToUpdate;
            OldEntryFileName = EntryToUpdate->fileNamePtr;
            if ( OldEntryFileName )
              ExFreePoolWithTag(OldEntryFileName, 0); // Freed!
            *(UNICODE_STRING *)&OldEntry->filenameLength = newUnicodeString;
            ExReleaseFastMutexUnsafe(&entryToUpdate->mutex);
            v13 = (const void **)Context;
          }
        }
      }
    }
    if ( FltObject )
      FltObjectDereference(FltObject);
    if ( v13 )
      FltReleaseContext(v13);
    if ( Src[1] )
      ExFreePoolWithTag(Src[1], 0);
    result = (unsigned int)v14;
  }
  else
  {
    result = v11;
  }
  return result;
}

There are checks in place preventing us from updating rogue offsets and performing OOB reads, BUT the old UNICODE_STRING.Buffer does get freed. We also see an example of proper locking of the FAST_MUTEX embedded inside every entry(this is the patch to WimCbEnumOverlay).

Thoughts

Now the path is pretty clear. We gonna call WimCbEnumOverlay in a few threads, while calling WimCbUpdateOverlay in another.

At the same time we can spray the heap with objects that enter the Paged Pool of the same size as the string buffer, maybe a WNF object as shown in my CVE-2021-31956 analysis.

If we can get the string buffer freed while another thread is performing a copy, we might be able to allocate new structures on it.
If those structures contain kernel pointers, we can leak them to userspace, completing the attack.

One way to prolong the race window could be to use super long directory names so the copy takes a longer time.
However, this depends on the target to enable LongPathsEnabled from the registry, which is not enabled by default.

We’ll also require the ability to obtain a handle to a volume(F drive in the example above).
In most scenarios this requires admin privileges already… which is pretty sad.
I had an idea which is to map a network drive(Medium IL) and use a handle to the network drive, but NtFsControlFile does not like that and denies our handle.

TLDR:
I’m struggling to trigger the exploit from medium/low IL.
Would love a helping hand/a person to collab with!

Update

After reaching out to k0shl, he pointed out that it’s possible to open a volume handle from Medium IL only in one case; If that volume is mapped from a second disk added via VMWare settings.

I’ve tested it on HyperV and it’s not the case. Seems like a VMWare bug maybe?
Anyways, after porting it to VMWare and enabling special pool, I finally got the poc working on the newest build of Windows 11(with wof.sys replaced of course).

see the UAF read above

扫一扫，分享到微信

微信分享二维码

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

人不狠话不多