CVE-2023-35359 analysis

Tale of my first cve

Introduction

In a previous post regarding filesystem bugs, I mentioned that I found an interesting behaviour pertaining to the dispatchment of unhandled exceptions.
With the bug being fixed in August’s patch tuesday as CVE-2023-35359, I can finally share about it publicly.

The bug itself is pretty useless and almost always non-exploitable(afaik), but the patch is huge and worth a blog post :)

I’ll be writing about the bug itself, how I found it, my expected patch and the actual patch by Microsoft.

Executive Summary

When an unhandled exception occurs on Windows, the program will involuntarily attempt to awake the Windows Error Reporting(WER) service for logging and analysis.
In the case where the awake call fails, for example when the service is explicitly marked as Disabled, the faulting program will create a WerFault.exe child to collect program specific statistics.
If by any chance the faulting program is a privileged process impersonating our current user, we will be able to hijack the process creation using a spoofed DOS device map and execute arbitrary code as high integrity.

The conditions are:

• WER service marked as disabled
• Privileged process P impersonating medium IL user
• Unhandled exception in P while under impersonation

The first condition is pretty common due to privacy and storage concerns, but the other two are really difficult to satisfy.

In the next section I’ll go into the technical details and root cause analysis of the bug.
Impersonated device map technique will not be discussed since I’ve previously written about it.

Root Cause Analysis

Here’s a sample program to simulate an unhandled exception:

#include <stdio.h>

int main(int argc, char **argv)
{
    getchar();
    *(int *)0 = 0;

    return 0;
}

Programmers are expected to handle their own exceptions using SEH(try-except) if using C or C++ Exception Handling(try-catch) if using C++.

Unhandled exceptions on Windows fall back to the default exception handler KernelBase!UnhandledExceptionFilter.

LONG __stdcall UnhandledExceptionFilter(struct _EXCEPTION_POINTERS *ExceptionInfo)
{
  ...

  if ( v3->ExceptionCode == -1073740791
    && ((unsigned int)BasepIsKernelDebuggerPresent() || (unsigned int)BasepIsDebugPortPresent()) )
  {
    DbgPrint_0("\r\nSTATUS_STACK_BUFFER_OVERRUN encountered\r\n");
    __debugbreak();
  }

  ...

    if ( !v14 || v14 == 126 )
    {
      v8 = BasepReportFault(ExceptionInfo, 1i64);
      v28 = v8;
      v29 = 1;
    }
  }
  
  ...

}

This function checks if a debugger is attached, and breaks into it if possible.
Otherwise, execution is passed to Kernel32!BasepReportFault to report the crash, which is a wrapper around Kernel32!WerpReportFault and eventually calls into Kernel32!WerpReportFaultInternal.

__int64 __fastcall WerpReportFaultInternal(__int64 a1)
{
  ...

  status = RtlWerpReportException(v17, v39, v46, v32, 0, &v33);

  ...

  if ( status >= 0 )
  {
    v20 = 1769483;
    if ( status == 1769483 )
    {
      DbgPrintEx(
        0x96u,
        0,
        "WER/ReportFault:%u: ERROR RtlWerpReportException failed: too many concurrent workers\n",
        952i64);
      goto LABEL_49;
    }
    goto LABEL_26;
  }

  ...
  
    v21 = StartCrashVertical(v6, v46, v32, &v33);
    
  ...

LABEL_26:

  ...
   
  if ( v34 )
    NtClose(v34);
  if ( TargetHandle )
    NtClose(TargetHandle);
  if ( v5 )
    NtClose(v5);
  if ( v4 )
    NtClose(v4);
  if ( v1 )
    UnmapViewOfFile(v1);
  if ( v6 )
    NtClose(v6);
  if ( v33 )
    NtClose(v33);
  return MapReturnCode(v20);
}

This function calls into ntdll!RtlWerpReportException, which is responsible for awaking the WER service(via an ETW trigger) and sending messages to it(via ALPC as mentioned here).

If the call succeeds, the service routine WerSvc!CWerService::SvcReportCrash will be invoked to organize crash statistics.
Finally, before the faulting process terminates, a thread is created to launch WerFault.exe as a child process using an auxiliary dll export Faultrep!CreateCrashVerticalProcess which eventually calls CreateProcessAsUserW.

In the event where the service is explicitly disabled, ntdll!RtlWerpReportException can’t wake it up and fails with an error status.
As shown in the pseudocode above, Kernel32!WerpReportFaultInternal takes things into its own hands and calls its own version of CreateCrash, Kernel32!StartCrashVertical

This function interestingly calls CreateProcessW instead.

As we’ve previously discussed, CreateProcessW is vulnerable to the impersonated device map attack because it uses its impersonation token while trying to look up the process image, but equips the eventual process with its primary token which can be of high privilege.

CreateProcessAsUserW on the other hand already takes a token handle as an argument.
In our case, the primary token of the faulting process is passed to the function, which does not follow our spoofed device map if it’s of high privilege, and thus cannot be exploited.

Expected Patch

I thought the bug probably arised because the developer working on Kernel32!StartCrashVertical is unaware that a similar function exists in Faultrep.dll.
My patch would be to either call into Faultrep.dll or replace the CreateProcessW call with a call to CreateProcessAsUserW.

Microsoft’s eventual patch is much more drastic.

The Patch

After receiving news of the patch, I launched procmon to view the stack traces like shown above.
To my surprise, the stack traces are exactly the same as before, which meant that the fix was on a kernel level.

I diffed ntoskrnl.exe before and after the patch and found some additional functions and modifications.

ObpUseSystemDeviceMap sounds really interesting as an added function, and ObpLookupObjectName is called when loading a process image from disk so the modification to it is likely Microsoft’s patch.

if ( objectType == IoFileObjectType && ObpUseSystemDeviceMap(ObjectNameRef, ObjectNameLength, a9, v14) )
  finalAttribute = initialAttribute | OBJ_IGNORE_IMPERSONATED_DEVICEMAP;

The patch is applied to ObpLookupObjectName to ignore the device map from the impersonation token if the object to be looked up is a file object and the call to ObpUseSystemDeviceMap succeeds.

ObpUseSystemDeviceMap

bool __fastcall ObpUseSystemDeviceMap(PUNICODE_STRING ObjectName, ULONG Length, ULONG64 x, ULONG64 y)
{
  WCHAR *v5; // rax
  WCHAR v6; // di
  WCHAR v7; // si
  WCHAR *v8; // rcx
  bool result; // al

  result = 0;
  if ( (*(_DWORD *)(&KeGetCurrentThread()[1].SwapListEntry + 1) & 8) != 0 && ObjectName->Length >= 0xEu )
  {
    v5 = (WCHAR *)RtlGetNtSystemRoot();
    v6 = RtlUpcaseUnicodeChar(*v5);
    v7 = RtlUpcaseUnicodeChar(ObjectName->Buffer[4]);
    if ( (unsigned int)Feature_MSRC79577_ObpDriveRemappingMitigation__private_IsEnabled() )
    {
      v8 = ObjectName->Buffer;
      if ( v8[5] == ':' && v8[6] == '\\' && v6 == v7 )
        result = 1;
    }
  }
  return result;
}

NT Paths start with \??\ so this just checks if the relative path starts with C:\, assuming C drive as system root.

In essence it means that file operations will no longer follow the device map of the impersonated token if the destination lies on a system root drive.
In my opinion this successfully eradicates the impersonated device map bug class that’s public for 8 years since James Forshaw’s discovery, how amazing is that!

Related Bugs

The first publicly documented bug using this technique should be CVE-2015-1644 by James Forshaw.

During that period attacks were prevalent on redirecting LoadLibrary calls to load arbitrary DLLs.
Microsoft subsequently introduced the OBJ_IGNORE_IMPERSONATED_DEVICEMAP flag but only applied it to PE loading operations.

Bugs from CreateProcessW and even read/write operations existed for many years, with the most recent one being CVE-2023-36874.
This bug is patched a month before mine and also concerns WER.
Instead of coercing a process creation, it exploits a triggerable CreateProcessW call under impersonation to execute arbitrary binaries.

I believe the July patch simply disabled this code path

__int64 __fastcall CWerComReport::SubmitReport(CWerComReport *this, unsigned __int16 *a2, unsigned int a3, struct IWerReportSubmitCallback *a4, unsigned __int16 **a5, unsigned int *a6)
{
   
   ...

  if ( (unsigned __int8)wil::details::FeatureImpl<__WilFeatureTraits_Feature_MSRC80633_DisableWerCplSupport>::__private_IsEnabled(&`wil::Feature<__WilFeatureTraits_Feature_MSRC80633_DisableWerCplSupport>::GetImpl'::`2'::impl) )
    return 0x80004001i64;

  v11 = CAutoImpersonate::ImpersonateUserHighestPrivs((CAutoImpersonate *)v12);

  ...

}

Not sure what made them pull the trigger this time.

Bug Discovery

How did I discover this bug?
Well it’s anti-climatic but I simply rebooted my machine, launched procmon and spoofed my device map while waiting for services to initialize.

One very popular(you could argue inbuilt) third party service threw an exception while on impersonation because it couldn’t find one of its libraries, and I caught it on procmon trying to locate WerFault.exe in my spoofed directory.

Nevertheless I’m very grateful to play a part in the mitigation of a bug class and receive my first CVE.

1337 bugs shall come.