CVE-2022-23270 – Windows Server VPN Remote Kernel Use After Free Vulnerability (Part 2)

CVE-2022-23270 – Windows Server VPN Remote Kernel Use After Free Vulnerability (Part 2)

Following yesterday’s Microsoft VPN vulnerability, today we’re presenting CVE-2022-23270, which is another windows VPN Use after Free (UaF) vulnerability that was discovered through reverse engineering and fuzzing the raspptp.sys kernel driver. This presents attackers with another chance to perform denial of service and potentially even achieve remote code execution against a target server.

Affected Versions

The vulnerability affects most versions of Windows Server and Windows Desktop since Windows Server 2008 and Windows 7 Respectively. To see a full list of affected Windows versions check the official disclosure post on MSRC:

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-23270

The vulnerability affects both server and client use cases of the raspptp.sys driver and can potentially be triggered in both cases. This blog post will focus on triggering the vulnerability against a server target.

Introduction

CVE-2022-23270 is heavily dependent on the implementation of the winsock Kernel (WSK) layer in raspptp.sys, to be successfully triggered. If you want to learn more about the internals of raspptp.sys and how it interacts with WSK, we suggest you read our write up for CVE-2022-21972 before continuing:

CVE-2022-21972: Windows Server VPN Remote Kernel Use After Free Vulnerability

CVE-2022-23270 is a Use after Free (UaF) resulting in Double Free that occurs as the result of a race condition. It resides in the implementation of PPTP Calls in the raspptp.sys driver.

PPTP implements two sockets; a TCP control connection and a GRE data connection. Calls are setup and managed by the control connection and are used to identify individual data streams handled by the GRE connection. The Call functionality makes it easy for PPTP to multiplex multiple different streams of VPN data over one connection.

Now we know in simple terms what PPTP calls are, lets see how they can be broken!

The Vulnerability

This section explores the underlying vulnerability.  We will then move on to triggering the vulnerable code on the target.

PPTP Call Context Objects

PPTP calls can be created through an IncomingCallRequest or an OutgoingCallRequest control message. The raspptp.sys driver creates a call context structure when either of these call requests are initiated by a connected PPTP client. The call context structures are designed to be used for tracking information and buffering GRE data for a call connection. For this vulnerability construction of the objects by raspptp.sys is unimportant we instead care about how they are accessed.

Accessing the Call Context

There are two ways in which handling a PPTP control message can retrieve a call context structure. Both methods require the client to know the associated call ID for the call context structure. This ID is randomly generated by the server sent to the client within the reply to the Incoming or Outgoing call request. The client then uses that ID in all subsequent control messages sent to the server that relate to that specific call. See the PPTP RFC (https://datatracker.ietf.org/doc/html/rfc2637) for more information on how this is handled.

raspptp.sys uses two methods to access the call context structures when parsing control messages:

• Globally accessible Call ID indexed array.
• PPTP control connection context stored link list.

The difference between these two access methods is scope. The global array can retrieve any call allocated by any control connection, but the linked list only contains calls relating to the control connection containing it.

Let’s go a bit deeper into these access methods and see if they play nicely together…

Linked List Access

The linked list access method is performed through two functions within raspptp.sys. EnumListEntry which is used to iterate through each member of the control connection call linked list and EnumComplete which is used to end the current loop and reset state.

while ( 1 )
{
    EnumRecord = EnumListEntry(
    &lpPptpCtlCx->CtlCallDoubleLinkedList,
    (LIST_ENTRY *)&ListIterator,
    &lpPptpCtlCx->pPptpAdapterCtx->PptpAdapterSpinLock);
    if ( !EnumRecord )
        break;
    EnumCallCtx = (CtlCall *)(EnumRecord - 2);
    if ( EnumRecord != (PVOID *)16 && EnumCallCtx->CallAllocTag == 'CPTP' )
        CallEventOutboundTunnelEstablished(EnumCallCtx);
}
Itreator = (LIST_ENTRY *)&ListIterator;
EnumComplete(Itreator, (KSPIN_LOCK)&lpPptpCtlCx->pPptpAdapterCtx->PptpAdapterSpinLock);

The ListIterator variable is used to store the current linked list entry that has been reached in the list so that the loop can continue from this point on the next call to EnumListEntry. EnumComplete simply resets the ListIterator variable once it’s done with. The way in which this code appears in the raspptp.sys driver can change around slightly but the overall method is the same. Call EnumListEntry repeatedly until it returns null and then call EnumComplete to tidy up the iterator.

Global Call Array

The global array access method is handled through a function called CallGetCall:

CtlCall *__fastcall CallGetCall(PptpAdapterContext *AdapterCtx, unsigned __int64 CallId)
{
    PptpAdapterContext *lpAdapterCtx;
    unsigned __int64 lpCallId;
    CtlCall *CallEntry;
    KIRQL curAdaperIRQL;
    unsigned __int64 BaseCallID;
    unsigned __int64 CallIdMaskApplied;
lpAdapterCtx = AdapterCtx;
lpCallId = CallId;
CallEntry = 0i64;
curAdaperIRQL = KeAcquireSpinLockRaiseToDpc(&AdapterCtx->PptpAdapterSpinLock);
BaseCallID = (unsigned int)PptpBaseCallId;
lpAdapterCtx->HandlerIRQL = curAdaperIRQL;
if ( lpCallId >= BaseCallID && lpCallId < (unsigned int)PptpMaxCallId )
{
    if ( PptpCallIdMaskSet )
    {
        CallIdMaskApplied = (unsigned int)lpCallId & PptpCallIdMask;
        if ( CallIdMaskApplied < (unsigned int)PptpWanEndpoints )
        {
            CallEntry = lpAdapterCtx->PptpWanEndpointsArray + CallIdMaskApplied;
            if ( CallEntry )
                {
                    if ( CallEntry->PptpWanEndpointFullCallId != lpCallId )
                        CallEntry = 0i64;
                }
        }
    }
    else
    {
        CallEntry = lpAdapterCtx->PptpWanEndpointsArray + lpCallId - BaseCallID;
    }
}

KeReleaseSpinLock(&lpAdapterCtx->PptpAdapterSpinLock, curAdaperIRQL);

return CallEntry;

}

This function effectively just retrieves the array slot that the call context structure should be stored in based on the provided call ID. It then returns the structure at that entry provided that it matches the specified ID and is in fact a valid entry.

So, what’s the issue? Both of these access methods look pretty harmless, right? There is one subtle and simple issue in the way these access methods are used. Locking!

Cross Thread Access?

CallGetCall is intended to be able to retrieve any call allocated by any currently connected control connection. Since a control connection doesn’t care about other control connection owned calls the control connection state machine should have no use for CallGetCall or at least, according to the PPTP RFC, it shouldn’t. However, this isn’t the case there are several control connection methods in raspptp.sys that use CallGetCall instead of referencing the internal control connection linked list!

If CallGetCall lets us access other control connection call context structures and certain parts of the PPTP handling can occur concurrently, then we can theoretically access the same call context structure in two different threads at the same time! This is starting to sound like a recipe for some racy memory corruption conditions.

Lock and Roll

Both the linked list access method and the CallGetCall function reference a PptpAdapterSpinLock variable on a global context structure. This is a globally accessible kernel spin lock that is to be used to prevent concurrent access to things which can be accessed globally. Using this should make any concurrent use of either call context list access method safe, right?

This isn’t the case at all. Looking at the above pseudo code the lock in CallGetCall is only actually held when we are searching through the list, which is great for the lookup but it’s not held once the call structure is returned. Unless the caller re locks the global lock before using the context structure (spoiler alert, it does not) then we have a potential window for unsafe concurrent access.

Concurrent access doesn’t necessarily mean we have a vulnerability. To prove that we have a vulnerability, we need two code locations that could cause a further issue when running with access to the object at the same time. For example, any form of free operation performed on the structure in this scenario could be a good source of an exploitable issue.

Getting Memory Corruption

Within the raspptp.sys driver there are many places where the kind of access we’re looking for can occur and cause different kinds of issues. Going over all of them is probably an entire series worth of blog posts that we can’t imagine anyone really wants. The one we ended up using for the Proof of Concept (PoC) involves the following two operations:

• Closing A Control Connection
  • When a control connection is closed the control connections call linked list is walked and each call context structure is appropriately de-initialised and freed. This operation is performed by a familiar function, CtlpCleanup.
• Sending an OutgoingCallReply control message with an error code set
  • If an OutgoingCallReply message is sent with an error set the call structure that it relates to is freed. The CallGetCall function is used for looking up the call context structure in this control message handling, which means we can use it to perform the free while the control connection close routine is running in a separate thread.

These two conditions create a scenario where if both were to happen consecutively, a call context structure is freed twice, causing a Use after Free/Double Free issue!

Race Against the Machine!

To trigger the race we need to take the following high level steps:

• Create two control connections and initialise them so we can create calls.
• On the first connection, we create the maximum allowed number of calls the server will allow us to.
• We then consecutively close the first connection and start sending OutGoingCallReply messages for the allocated call IDs.
  • This realistically needs to be done in separate threads bound to separate CPU cores to guarantee true concurrency.
• Then we sit back and wait for the race to be won?

In practice, reliably implementing these steps is a lot more difficult than it would initially seem. The window for reliably triggering the race condition and the amount of time we have to do something useful once the initial free occurs is incredibly small, even in the best case scenario.

However, this does not mean that it cannot be achieved. With a significant amount of effort it is possible to greatly increase the reliability of triggering the vulnerability. There are many different factors that can be played with to build a path towards successful exploitation.

One Lock, Two Lock, Three Lock, Four!

Let’s take a look at the two bits of code we’re hoping to get perfectly aligned and see just how tricky this race condition is actually going to be.

The CtlpCleanup Linked List Iteration

for ( ListIterator = (LIST_ENTRY *)EnumListEntry(
    &lpCtlCtxToCleanup->CtlCallDoubleLinkedList,
    &iteratorState,
    &gAdapter->PptpAdapterSpinLock);
    ListIterator;
    ListIterator = (LIST_ENTRY *)EnumListEntry(
    &lpCtlCtxToCleanup->CtlCallDoubleLinkedList,
    &iteratorState,
    &lpCtlCtxToCleanup->pPptpAdapterCtx->PptpAdapterSpinLock) )
    {
        lpCallCtx = (CtlCall *)&ListIterator[-1];
        if ( ListIterator != (LIST_ENTRY *)16 && lpCallCtx->CallAllocTag == 'CPTP' )
        {
            ...
        CallCleanup(lpCallCtx); // this will eventually free the call strructure
    }
}

We can see here that the loop is fairly small. The main part that we are interested in is the call to CallCleanup that is performed on each Call structure in the control context linked list. Now unfortunately this function is not as simple as we would like. The function contains a large number of different paths to execute and could potentially have a variety of ways that make our race condition harder or easier to exploit. The section that is most interesting for us in our PoC is the following pseudo code snippet.

lpIRQL = KeAcquireSpinLockRaiseToDpc(&lpCallToClean->CtlCallSpinLock_A);
lpCallToClean->NdisVcHandle = 0i64;
lpCallToClean->CurIRQL = lpIRQL;
CallDetachFromAdapter(lpCallToClean);
KeReleaseSpinLock(&lpCallToClean->CtlCallSpinLock_A, lpCallToClean->CurIRQL);
if...
    CtlDisconnectCall(lpCallToClean);
    CallpCancelCallTimers(lpCallToClean);
    DereferenceRefCount(lpCallToClean); // Decrement from Ctl loop
    lpCallToClean->CurIRQL = KeAcquireSpinLockRaiseToDpc(&lpCallToClean->CtlCallSpinLock_A);
}
}
KeReleaseSpinLock(&lpCallToClean->CtlCallSpinLock_A, lpCallToClean->CurIRQL);

return DereferenceRefCount(lpCallToClean); // Freeing decrement

Here, a set of detach operations are performed to remove the call structure from the lists its stored in and appropriately decrease its internal reference count. A side effect of this detach phase is that the call context structure is removed from both the linked list and global array. This means that if one thread gets to far through processing a call context structure free before the other one retrieves it from the respective list, the race will already be lost. This further adds to the difficulty in getting these two sections of code lined up.

Ultimately the final call to DereferenceRefCount causes the release of the underlying memory which in our scenario it does by calling the call context structures internal free function pointer to the CallFree function. Before we go over what CallFree does, lets look at the other half of the race condition.

OutgoingCallReply Handling

lpCallOutgoingCallCtx = CallGetCall(lpPptpCtlCx->pPptpAdapterCtx, ReasonCallIdMasked);
if ( lpCallOutgoingCallCtx )
{
    CallEventCallOutReply(lpCallOutgoingCallCtx, lpCtlPayloadBuffer);
}

The preceding excerpt of pseudo code is the bit of the OutgoingCallReply handling that we will be using to access the call context structures from a separate thread. Let’s take a look at the logic in this function which will also free the call context object!

lpCallCtx->CurIRQL = KeAcquireSpinLockRaiseToDpc(&lpCallCtx->CtlCallSpinLock_A); 
... 
KeReleaseSpinLock(&lpCallCtx->CtlCallSpinLock_A, lpCallCtx->CurIRQL); 
if ( OutGoingCallReplyStatusCode ) { 
    CallSetState(lpCallCtx, 0xBu, v8, 0); CallCleanup(lpCallCtx);
}

This small code snippet from CallEventCallOutReply represents the code that is relevant for our PoC. Effectively if the status field of the OutgoingCallReply message is set then a call to CallCleanup happens and again will eventually result in CallFree being hit.

CallFree

The call free function releases resources for multiple sub objects stored in the call context as well as the call context itself:

void __fastcall CallFree(CtlCall *CallToBeFreed)
{
    CtlCall *lpCallToBeFreed;
    _NET_BUFFER_LIST *v2;
    NDIS_HANDLE v3;
    NDIS_HANDLE v4;
    PNDIS_HANDLE v5;
    PNDIS_HANDLE v6;
    PNDIS_HANDLE v7;
if ( CallToBeFreed )
{
    lpCallToBeFreed = CallToBeFreed;
     ...
     v2 = lpCallToBeFreed->CtlNetBufferList_A;

   if ( v2 )

       ChunkLChunkength(v2);

       v3 = lpCallToBeFreed->CtlCallWorkItemHandle_A;

if ( v3 )

     NdisFreeIoWorkItem(v3);

     v4 = lpCallToBeFreed->CtlCallWorkItemHandle_B;

if ( v4 )

NdisFreeIoWorkItem(v4);

v5 = lpCallToBeFreed->hCtlCallCloseTimeoutTimerObject;

if ( v5 )

NdisFreeTimerObject(v5);

v6 = lpCallToBeFreed->hCtlCallAckTimeoutTimerObject;

if ( v6 )

NdisFreeTimerObject(v6);

v7 = lpCallToBeFreed->hCtlDieTimeoutTimerObject;

if ( v7 )

NdisFreeTimerObject(v7);

ExFreePoolWithTag(lpCallToBeFreed, 0);

}

}

In CallFree, none of the sub-objects have their pointers Nulled out by raspptp.sys. This means that any one of these objects will cause potential double free conditions to occur, giving us a few different locations where we can expect a potential issue to occur when triggering the vulnerability.

Something that you may notice looking at the code snippets for this vulnerability is that there are large portions of overlapping locks. These will in effect cause each thread not to be able to enter certain sections of the cleanup and freeing process at the same time, which makes the race condition harder to predict. However, it does not prevent it from being possible.

We have knowingly not included many of the other hazards and caveats for triggering this vulnerability, as there are just too many different factors to go over, and in actuality a lot of them are self-correcting (luckily for us). The main reason we can ignore a lot of these hazards is that none of them truly stop the two threads from entering the vulnerable condition!

Proof of Concept

We will not yet be publishing our PoC for this vulnerability to allow time for patches to be fully adopted. This unfortunately makes it hard to show the exact process we took to trigger the vulnerability, but we will release the PoC script at a later date! For now here is a little sneak peak at the outputs:

[+] Race Condition Trigger Attempt: 1, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 2, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 3, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 4, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 5, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 6, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 7, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 8, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 9, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 10, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 11, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 12, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 13, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 14, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 15, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 16, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 17, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 18, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 19, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 20, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 21, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 22, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 23, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 24, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 25, With spacing 0 and sled 25
[+] Race Condition Trigger Attempt: 26, With spacing 0 and sled 25
[****] The Server Has Crashed!

A Wild Crash Appeared!

The first step in PoC development is achieving a successful trigger of a vulnerability and usually for kernel vulnerabilities this means causing a crash! Here it is. A successful trigger of our race condition causing the target server to show us the iconic Blue Screen of Death (BSOD):

Now this crash has the following vulnerability check analysis and its pretty conclusive that we’ve caused one of the intended double free scenarios.

*******************************************************************************
* *
* Vulnerabilitycheck Analysis *
* *
*******************************************************************************
KERNEL_SECURITY_CHECK_FAILURE (139)

A kernel component has corrupted a critical data structure. The corruption

could potentially allow a malicious user to gain control of this machine.

Arguments:

Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).

Arg2: ffffa8875b31e820, Address of the trap frame for the exception that caused the vulnerabilitycheck

Arg3: ffffa8875b31e778, Address of the exception record for the exception that caused the vulnerabilitycheck

Arg4: 0000000000000000, Reserved

Devulnerabilityging Details:
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec

Value: 5327
Key : Analysis.DevulnerabilityAnalysisManager

Value: Create
Key : Analysis.Elapsed.mSec

Value: 22625
Key : Analysis.Init.CPU.mSec

Value: 46452
Key : Analysis.Init.Elapsed.mSec

Value: 9300845
Key : Analysis.Memory.CommitPeak.Mb

Value: 82
Key : FailFast.Name

Value: CORRUPT_LIST_ENTRY
Key : FailFast.Type

Value: 3
Key : WER.OS.Branch

Value: fe_release
Key : WER.OS.Timestamp

Value: 2021-05-07T15:00:00Z
Key : WER.OS.Version

Value: 10.0.20348.1
VULNERABILITYCHECK_CODE: 139
VULNERABILITYCHECK_P1: 3
VULNERABILITYCHECK_P2: ffffa8875b31e820
VULNERABILITYCHECK_P3: ffffa8875b31e778
VULNERABILITYCHECK_P4: 0
TRAP_FRAME: ffffa8875b31e820 – (.trap 0xffffa8875b31e820)

NOTE: The trap frame does not contain all registers.

Some register values may be zeroed or incorrect.

rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000003

rdx=ffffcf88f1a78338 rsi=0000000000000000 rdi=0000000000000000

rip=fffff8025f8d8ae1 rsp=ffffa8875b31e9b0 rbp=ffffcf88f1ae0602

r8=0000000000000010 r9=000000000000000b r10=fffff8025b0ddcb0

r11=0000000000000001 r12=0000000000000000 r13=0000000000000000

r14=0000000000000000 r15=0000000000000000

iopl=0 nv up ei pl nz na pe nc

NDIS!ndisFreeNblToNPagedPool+0x91:

fffff802`5f8d8ae1 cd29 int 29h

Resetting default scope
EXCEPTION_RECORD: ffffa8875b31e778 – (.exr 0xffffa8875b31e778)

ExceptionAddress: fffff8025f8d8ae1 (NDIS!ndisFreeNblToNPagedPool+0x0000000000000091)

ExceptionCode: c0000409 (Security check failure or stack buffer overrun)

ExceptionFlags: 00000001

NumberParameters: 1

Parameter[0]: 0000000000000003

Subcode: 0x3 FAST_FAIL_CORRUPT_LIST_ENTRY
PROCESS_NAME: System
ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.
EXCEPTION_CODE_STR: c0000409
EXCEPTION_PARAMETER1: 0000000000000003
EXCEPTION_STR: 0xc0000409
STACK_TEXT:

ffffa8875b31dcf8 fffff8025b354ea2 : ffffa8875b31de60 fffff8025b17bb30 ffff9200174e5180 0000000000000000 : nt!DbgBreakPointWithStatus

ffffa8875b31dd00 fffff8025b3546ed : ffff920000000003 ffffa8875b31de60 fffff8025b22c910 0000000000000139 : nt!KiVulnerabilityCheckDevulnerabilityBreak+0x12

ffffa8875b31dd60 fffff8025b217307 : ffffa8875b31e4e0 ffff92001732a180 ffffcf88ef584700 fffffff600000004 : nt!KeVulnerabilityCheck2+0xa7d

ffffa8875b31e4c0 fffff8025b229d69 : 0000000000000139 0000000000000003 ffffa8875b31e820 ffffa8875b31e778 : nt!KeVulnerabilityCheckEx+0x107

ffffa8875b31e500 fffff8025b22a1b2 : 0000000000000000 fffff8025f5a1285 ffffcf88edd5c210 fffff8025b041637 : nt!KiVulnerabilityCheckDispatch+0x69

ffffa8875b31e640 fffff8025b228492 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiFastFailDispatch+0xb2

ffffa8875b31e820 fffff8025f8d8ae1 : ffffcf88ef584c00 ffffcf88ef584700 0000000000000000 0000000000000000 : nt!KiRaiseSecurityCheckFailure+0x312

ffffa8875b31e9b0 fffff8025f8d5d3d : ffffcf88f1a78350 0000000000000000 ffffcf88f1ae06b8 01000000000002d0 : NDIS!ndisFreeNblToNPagedPool+0x91

ffffa8875b31e9e0 fffff80262bd2f7d : ffffcf88f1ae06b8 fffff80262bda000 ffffcf88f1a78050 ffffcf88f202dd70 : NDIS!NdisFreeNetBufferList+0x11d

ffffa8875b31ea20 fffff80262bd323f : ffffcf88f202dd70 ffffcf88ef57f1a0 ffffcf88ef1fc7e8 ffffcf88f1ae0698 : raspptp!CallFree+0x65

ffffa8875b31ea50 fffff80262bd348e : ffffcf88f1a78050 0000000000040246 ffffa8875b31eaa0 0000000000000018 : raspptp!CallpFinalDerefEx+0x7f

ffffa8875b31ea80 fffff80262bd2bad : ffffcf88f1ae06b8 ffffcf88f1a78050 000000000000000b ffffcf88f1a78050 : raspptp!DereferenceRefCount+0x1a

ffffa8875b31eab0 fffff80262be37b2 : ffffcf88f1ae0660 ffffcf88f1ae0698 ffffcf88f1ae06b8 ffffcf88f1a78050 : raspptp!CallCleanup+0x61d

ffffa8875b31eb00 fffff80262bd72bd : ffffcf8800000000 ffffcf88f15ce810 0000000000000080 fffff80262bd7290 : raspptp!CtlpCleanup+0x112

ffffa8875b31eb90 fffff8025b143425 : ffffcf88ef586040 fffff80262bd7290 0000000000000000 0000000000000000 : raspptp!MainPassiveLevelThread+0x2d

ffffa8875b31ebf0 fffff8025b21b2a8 : ffff92001732a180 ffffcf88ef586040 fffff8025b1433d0 0000000000000000 : nt!PspSystemThreadStartup+0x55

ffffa8875b31ec40 0000000000000000 : ffffa8875b31f000 ffffa8875b319000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x28
SYMBOL_NAME: raspptp!CallFree+65
MODULE_NAME: raspptp
IMAGE_NAME: raspptp.sys
STACK_COMMAND: .thread ; .cxr ; kb
BUCKET_ID_FUNC_OFFSET: 65
FAILURE_BUCKET_ID: 0x139_3_CORRUPT_LIST_ENTRY_raspptp!CallFree
OS_VERSION: 10.0.20348.1
BUILDLAB_STR: fe_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {5d4f996e-8239-e9e8-d111-fdac16b209be}
Followup: MachineOwner

---------

It turns out that the double free trigger here is triggering a kernel assertion to be raised on a linked list. The cause of this is one of those sub objects on the call context structure we mentioned earlier. Now, while crashes are great for PoC’s they are not great for exploits, so what do we need to do next if we want to look at further exploitation more seriously?

Exploitation – Next Steps

The main way in which this particular double free scenario can be exploited would be to attempt to spray objects into the kernel heap that will instead be incorrectly freed by our second free instead of causing the above kernel vulnerability check.

The first object that might make a good contender is the call context structure itself. If we were to spray a new call context into the freed memory between the two frees being run then we would have a freed call context structure still connected to a valid and accessible control connection. This new call context structure would be comprised of mostly freed sections of memory that can then be used to cause further memory corruption and potentially achieve kernel RCE against a target server!

Conclusion

Race conditions are a particularly tricky set of vulnerabilities, especially when it comes to getting reliable exploitation. In this scenario we have a remarkably small windows of opportunity to do something potentially dangerous. Exploit development, however, is the art of taking advantage of small opportunities. Achieving RCE with this vulnerability might seem like an unlikely event but it is certainly possible! RCE is also not the only use of this vulnerability with local access to a target machine; it doubles as an opportunity for Local Privilege Escalation (LPE). All this makes CVE-2022-23270 something that in the right hands could be very dangerous.

Timeline

• Vulnerability Reported To Microsoft – 29 October 2021
• Vulnerability Acknowledged – 29 October 2021
• Vulnerability Confirmed – 11 November 2021
• Patch Release Date Confirmed – 12 January 2022
• Patch Release – 10 May 2022

The post CVE-2022-23270 – Windows Server VPN Remote Kernel Use After Free Vulnerability (Part 2) appeared first on Nettitude Labs.

Article Link: CVE-2022-23270 - Windows Server VPN Remote Kernel Use After Free Vulnerability (Part 2) - Nettitude Labs

1 post - 1 participant

Read full topic