CVE-2022-37969 Windows Local Privilege Escalation PoC
authors: Ricardo Narvaja & Daniel Kazimirow (Solid)
For demonstration purposes only. Complete exploit works on vulnerable Windows 11 21H2 systems.
Functional PoC based on previously published information by Zscaler
Checkout the writeup Understanding the CVE-2022-37969 Windows Common Log File System Driver Local Privilege Escalation.
Usage
Understanding the CVE-2022-37969 Windows Common Log File System Driver Local Privilege Escalation.
Exploitation walkthrough:
- Creating the initial BLF log file
- Creating multiple random BLF log files
- Crafting the initial log file
- Performing a controlled Heap Spray
- Preparing the methods CreatePipe() / NtFsControlFile()
- Once memory was prepared will trigger the vulnerability
- Reading the System Token
- Validating the token
- Overwrite our process’s token with the system one
- Executing process as system
- Reversing the Patch: Analyzing the structures
- Corrupting the “pContainer” pointer
- Revisiting the Patch
- Corrupting the SignatureOffset
- Corrupting more values
- Controlling the functions that allows to read the SYSTEM token
- Write our own process to achieve the local privilege escalation
- PoC source code
The scenario used here was Windows 11 21H2 (OS Build 22000.918) clfs.sys v10.0.22000.918
Creating the initial BLF log File
The first step is to create a file named MyLog.blf in the public folder (%public%), by using the CreateLogFile() function:
Creating multiple random BLF log files
Then it creates several log files with random names using a Loop.
And within the loop, it calls to our getBigPoolInfo() function:
It calls the NtQuerySystemInformation(), with 0x42 (66 decimal) as the first argument, it will return in v5 the information about the raids made in the bigpool, whose structure is of type SYSTEM_BIGPOOL_INFORMATION.
We have to call this function twice. The first one will return an error, but it will give us the correct size of the buffer to call the second time to obtain the desired information.
v5 will receive the information of the SYSTEM_BIG_POOL_INFORMATION structure.
The number of allocations in the bigpool, is stored in the first field called Count, in the second field there is an array of structures SYSTEM_BIGPOOL_ENTRY.
Then we’ll search through all the structures for the "Clfs" tag and the size 0x7a00.
It stores in an array called kernelAddrArray the VirtualAddress which is the first field of each structure that has CLFS tag and size 0x7a00. From now on, the pools that meet both conditions will be called: “right pools”.
In addition to store each right pool in the array, it stores the last right pool found in the content of a2 variable, which is used as argument of the function.
In this way a2 always points to the last right pool with CLFS tag and size 0x7a00 created.
The variable v26 always stores the previous right pool found since it is equal to v24 (v26=v24), before calling getBigPoolinfo(), but v24 is updated when leaving this call with the last right pool found, and v26 stays with de previous right pool found.
Then It subtracts both directions, and in case the result is negative, inverts the operands so that it is always positive.
In this way in v32 will stores the difference between the VirtualAddress of the last two right pool found.
Then it does something similar, in this case v23 is initially zero so it does v23=v32 the first time.
The next time in loop v23 it still has the same value and is not zero, so it breaks and goes here.
V32 has the last difference and v23 the previous one, if they are equal, it comes out and increments one, but resets the counter to zero.
The idea is to find 6 consecutive comparisons of CLFS tags and size 0x7a00 whose differences are equal, and that difference will be 0x11000. We will see when executing that when it finds 6 (since it starts from scratch) consecutive with equal distances it will give that value of difference between them.
There we see that he found 6 consecutive and left the loop of creating log files.
In the "public" folder we can see the files created
Crafting the initial log file:
Our craftFile() function opens the original file (MyLog.blf) and modifies it to trigger the bug.
After modifying the file, it's necessary to change the CRC32, otherwise we'll get a corrupt file error
This value is located at offset 0x80C of the file.
Performing a controlled Heap Spray
Next, it performs a HeapSpray, using the VirtualAlloc() function to allocate memory, at arbitrary addresses 0x10000 and 0x5000000 respectively, and saving in the second allocation (0x10000), the value 0x5000000, every 0x10 bytes.
Preparing the methods CreatePipe() / NtFsControlFile()
It uses CreatePipe() to create an anonymous pipe and call NtFsControlFile() using 0x11003c as an argument to add an attribute, later you can call this same function with the 0x110038 argument to read it.
More details of this method can be found HERE
There we see the input buffer that is the attribute we are adding, if we call NtFsControlFile() again with the argument 0x11038 in the output it should return this same attribute.
Search the pool for the tag of the created attribute (NpAt)
And when it finds it, it saves it in v30.Pointer the VirtualAddress of this pool.
V30.pointer+24 points to the AttributeValueSize in the kernel pool and saves it in one of the HeapSprays we’ve made before.
The idea is to write to that kernel address+8, to overwrite the AttributeValue.
The PipeAttribute structure has as its first field a LIST_ENTRY that has a size of 16 bytes, then a pointer to the name of the attribute that has a size of 8 bytes and then comes in 0x18 (24 decimal) the AttributeValueSize field that is the one we are storing in the HeapSpray.
After that, we load in CLFS.sys and ntoskrnl in usermode, and by using GetProcAddress() we find the addresses of the ClfsEarlierLsn() and SeSetAccessStateGenericMapping() functions.
Then we call the FindKernelModulesBase() function that will find the kernel base of both same modules using NtquerySystemInformation() this time with the SystemModuleInformation argument to return the info about all the modules.
In this way, we can calculate the offset of each function, and then obtain them in kernel
Once memory was prepared will trigger the vulnerability:
The pipeArbitraryWrite() function is called twice, there is a flag that initially is zero for the first call and when in the second call it is value 1, it will change the values of the HeapSpray.
In the first call in the 0x5000000 memory address, the following values are located
Remember that this value in addition to alloc in that direction, is stored in our HeapSpray.
This is how the memory is after the first call, as we said in the address around of 0x5000000
And in the HeapSpray from memory 0x10000 it will store the pointer to AttributeValueSize every 0x10 bytes, besides the pointer to 0x5000000.
Reading the System Token:
This sequence will trigger the bug:
CreateLogFile() is called again on the crafted file and on another with a random name.
AddLogContainer() is then called using the handles of those files.
The NtSetinformationFile() is called, and the handles are closed with which the pointer is corrupted (it'll be explained later)
The HeapSpray, prevents a BSOD from occurring at this point:
Setting a breakpoint there, we can see that the pointer is corrupt and points to our HeapSpray, with which we can handle the next two function calls of the vtable.
RAX takes the value 0x5000000 and jumps first to the function located at 0x5000000+18 and then to 0x5000000+8.
So first jump to fnClfsEarlierLsn() and then to fnSeSetAccessStateGenericMapping().
We trace from the breakpoint and see that it reaches CLFS!ClfsEarlierLsn().
This function is called exclusively because when it returns, it sets EDX to 0xFFFFFFFF
In the address 0xFFFFFFFF we had stored the result of the SYSTEM _EPROCESS & 0xFFFFFFFFFFFFFFF000
As we mentioned, when returning from CLFS!ClfsEarlierLsn(), RDX value is 0x00000000FFFFFFFF
We come to the second function nt!SeSetAccessStateGenericMapping()
This function is useful, since RCX points to our HeapSpray, and RDX value is 0xFFFFFFFF, whose content we control
The content of RCX+0x48 have the pointer to AttributeValueSize that was stored in v30.Pointer+24
That pointer value of AttributeValueSize is moved to RAX, then reads the contents of the address 0xFFFFFFFF where we had stored the address of the SYSTEM _EPROCESS & 0xFFFFFFFFFFFFFFF000.
Then overwrites in RAX+8 the next field which is the AttributeValue()
Of course, the AttributeValue would normally point in kernel to the attribute we added.
And now we’ll overwrite it with a pointer of the result of the system _EPROCESS & 0xFFFFFFFFFFFFFFF00.
That will mean that when we call the NtFsControlFile() function again, this time with the 0x110038 argument to read the attribute, instead of returning the "A” that were pointed by the AttributeValue pointer, it will now read from _EPRROCESS & 0xFFFFFFFFFFFFFFFFF000 the requested number of bytes and return it in the output buffer with which we can obtain in the first call the value of the SYSTEM TOKEN.
v9b is the start address of the Output Buffer where the content of the result of System EPROCESS & 0xFFFFFFFFFFFFFFF000 were copied.
To that he adds v14 which are the last 3 bytes of the System EPROCESS and then adds 0x4b8 which is the offset of Token for this version of Windows 11, then finds the contents of that address that will have saved the value of the System Token.
Validating the token
Remember that the last 4 bits were changed, it is not significant, so the value still matches.
Overwrite our process’s token with the system one
In the second call the value of Flag is 1 since it was incremented at the end of the first call.
There we see the order in which the values are stored
The address 0xFFFFFFFF with the value we have just found of the System Process Token.
And in the HeapSpray is the value of the Token address of my process to which I subtract 8. This value plus eight will be used as a target, remember that you wrote on the address pointed by RAX+8.
In the memory address starting on 0x5000000
We also see that it uses the name of other container, since the previous one is being used by the system process cannot be opened again or deleted.
Then the bug is triggered for the second time in the same way as it was in the first try.
It comes again to CLFS!ClfsEarlierLsn().
setting RDX to 0xFFFFFFFF
Then it comes to nt!SeSetAccessStateGenericMapping()
Read the address of the Token of my process minus 8 where is going to write
Then reads the SYSTEM TOKEN
And writes in the address of the Token of my process (it adds 8), the System Token
And that way my process is with the System Token
Once the token is written, we start a process to check the privileges, in this case, we launch Notepad.exe
Executing process as system:
Remember that this POC only works in Windows 11, in Windows 10 it will produce a BSOD, so you should make some modifications to work correctly, it is not explained in this blogpost.
Reversing the Patch:
Analyzing the structures
The structures and most of the documentation on the CLFS file format, we have taken from IONESCU's excellent work on CLFS Internals.
We can see that a check has been added in the function ClfsBaseFilePersisted::LoadContainerQ
The values that perform an addition, belongs to the _CLFS_BASE_RECORD_HEADER structure.
Note that the Base Block starts at offset 0x800 of the file, and ends at offset 0x71FF, corresponding the first 0x70 bytes to the Log Block Header
As a good practice, we can add the _CLF_LOG_BLOCK_HEADER structure on IDA
struct _CLFS_LOG_BLOCK_HEADER
{
UCHAR MajorVersion;
UCHAR MinorVersion;
UCHAR Usn;
char ClientId;
USHORT TotalSectorCount;
USHORT ValidSectorCount;
ULONG Padding;
ULONG Checksum;
ULONG Flags;
CLFS_LSN CurrentLsn;
CLFS_LSN NextLsn;
ULONG RecordOffsets[16];
ULONG SignaturesOffset;
};
Then we have the Base Record Header (_CLFS_BASE_RECORD_HEADER) that starts at the offset 0x870 from the beginning of the file and is 0x1338 bytes long.
If you want to import it to IDA, before you must add the following types and missing structures
typedef GUID CLFS_LOG_ID;
typedef UCHAR CLFS_LOG_STATE;
struct _CLFS_METADATA_RECORD_HEADER
{
ULONGLONG ullDumpCount;
};
Now is ready to be added:
typedef struct _CLFS_BASE_RECORD_HEADER
{
CLFS_METADATA_RECORD_HEADER hdrBaseRecord;
CLFS_LOG_ID cidLog;
ULONGLONG rgClientSymTbl[0x0b];
ULONGLONG rgContainerSymTbl[0x0b];
ULONGLONG rgSecuritySymTbl[0x0b];
ULONG cNextContainer;
CLFS_CLIENT_ID cNextClient;
ULONG cFreeContainers;
ULONG cActiveContainers;
ULONG cbFreeContainers;
ULONG cbBusyContainers;
ULONG rgClients[0x7c];
ULONG rgContainers[0x400];
ULONG cbSymbolZone;
ULONG cbSector;
USHORT bUnused;
CLFS_LOG_STATE eLogState;
UCHAR cUsn;
UCHAR cClients;
} CLFS_BASE_RECORD_HEADER, *PCLFS_BASE_RECORD_HEADER;
After including the structures, we notice that performs an addition between the cbSymbolZone and the address where the _CLFS_BASE_RECORD_HEADER ends. (start + 1338h)
Remember that cbSymbolZone was modified in the crafted log file from 0x000000F8 to 0x0001114B.
(offset 0x1b98 of the file)
0x800(offset of the start of the Base Block) + 0x70 (logBlockHeader) + 0x1328 (cbsymbolZone)
0x800+0x70+0x1328 = 0x1b98
Crafted cbsymbolZone on MyLog.blf file:
As the patch is in the CClfsBaseFilePersisted::LoadContainerQ function, we have to take a look at the CClfsBaseFilePersisted object.
Setting a breakpoint in CLFS!CClfsBaseFilePersisted::LoadContainerQ and when CreateLogFile is called with the handle of the crafted file it’ll break.
Call the CClfsBaseFile::GetBaseLogRecord function to get the address of the Base Log Record (_CLFS_BASE_RECORD_HEADER)
RAX will point to the _CLFS_BASE_RECORD_HEADER address
Note the _CLFS_BASE_RECORD_HEADER structure in memory and the cbsymbolZone field 0x1328
bytes forward
r14 stores the structure corresponding to the “this”, which is CClfsBaseFilePersisted since it is the this of the function CClfsBaseFilePersisted::LoadContainerQ.
The CClfsBaseFilePersisted structure in memory:
So, let's create a structure with length 0x21c0 to complete its fields while we reverse it (it's an undocumented structure) we'll call it struct_CClfsBaseFilePersisted
Inside the function CClfsBaseFile::GetBaseLogRecord() gets the pointer to _CLFS_BASE_RECORD_HEADER. and we know that the "this" in that function is the structure: struct_CClfsBaseFilePersisted.
Read two fields (offset 0x28 and 0x30)
Field 0x28 is a word and has the value 6, so we change the type to word in the structure.
For now, we rename it to constant 6 (const_6)
According to the documentation, 6 would be the number of blocks CLFS_METADATA_BLOCK_COUNT. The field could refer to this value.
And that pointer is at offset 0x30.
Note that the size shown there includes the header with length 0x10
When the ExAllocatePoolWithTag function is called, a few bytes are requested, but the header is not included, therefore, 0x90 bytes (0xa0 – 0x10) will be requested in the call.
Searching by text +30h], the instructions that write at offset 0x30 we found a long list, but filtering the list by the type of object CClfsBaseFilePersisted leaves us with few results and immediately find where that size is allocated, and the same tag. (Tip: Create and Initialize function names, are always the first to look at)
Since we still don't know the name, we'll put it pool_0x90, which is another undocumented structure, and we'll create a structure of that size.
The pool_0x90 in memory has another pointer at its own offset 0x30.
This other pointer points to the base block in the file (Base block starts at offset 0x800)
Image taken from the Zscaler blogpost:
The allocation is huge, because it contains the entire base block.
So, we will create a new structure of size 0x7a00 and call it BASE_BLOCK
The first 70 bytes we already knew correspond to _CLFS_LOG_BLOCK_HEADER and the following 0x1338 to _CLFS_BASE_RECORD_HEADER.
So, adding the start of the Base Block with the offset to the next record (which is 0x70), we get the _CLFS_BASE_RECORD_HEADER
The _CLFS_BASE_RECORD_HEADER on memory.
Looking at other methods of the same CClfsBaseFilePersisted object, in CClfsBaseFilePersisted::AddContainer you get with CClfsBaseFile::GetBaseLogRecord also the address of _CLFS_BASE_RECORD_HEADER.
Next, call CClfsBaseFile::OffsetToAddr using cbOffset, it gets the address of _CLFS_CONTAINER_CONTEXT, and stores cboffset in the rgbcontainers array which is at offset 0x328 of the _CLFS_BASE_RECORD_HEADER.
CClfsBaseFile::OffsetToAddr function is used to find structures addresses from offset
At this point, the container offset that will be stored at 0x328 is still 0, because we have not added a container yet.
the PoC calls CreateLogFile twice, the first time with the malformed file MyLog.blf and the second time with the normal MyLogxxx.blf file, so we must stop debugging twice in all the above places and take note in notepad of the addresses of the above structures for both files.
Let us fast forward a bit to CLFS!CClfsLogFcbPhysical::AllocContainer by setting a breakpoint on it and running there.
When the AddLogContainer() is reached on the POC, we stop at the breakpoint.
Let’s also set a breakpoint on the CClfsBaseFilePersisted::AddContainer+176 where we saw before that will find the offset and pointer to the _CLFS_CONTAINER_CONTEXT structure.
When the Debugger breaks, we can see that the offset is 0x1468.
In RAX will return the address of the _CLFS_CONTAINER_CONTEXT structure.
the structure is still empty because it was not added the container yet.
Note that the SignatureOffset=0x50 value that we wrote at offset 0x868 to the malformed file, subtracting the 0x800 from the start of the base block, will be in the _CLFS_LOG_BLOCK_HEADER structure at offset 0x68.
When the PoC calls AddLogContainer() function using the malformed file, at offset 0x68 of _CLFS_LOG_BLOCK_HEADER, instead of the 0x50 value we wrote there, is currently a 0xFFFF0050 in memory.
At some point, that value was altered by the program, in order to see when it happened, in the next execution, we will set a memory breakpoint on write.
The offset is stored at r15 + 0x328 (r15 points to the _CLFS_BASE_RECORD_HEADER structure)
RBX stores the offset 0x1468.
So, in the Base Block address + 0x70 + the offset 0x1468 that we found out, there will be the address of the CLFS_CONTAINER_CONTEXT container.
In CLFS_CONTAINER_CONTEXT structure at offset 0x18 will be the pContainer pointer that will be stored there, we can set a breakpoint on write and see when it is written.
This is the pointer that we must corrupt since in the function where the vulnerability is, it first reads the CLFS_CONTAINER_CONTEXT, then moves it to r15 and next reads the value of r15+18, which is this pointer that we have just set the Breakpoint on write.
it stores the pContainer at offset 0x1c0 of the struct_CClfsBaseFilePersisted structure.
After several times that it stops, we reach the moment where it gets corrupted. The top of the pointer address has been changed from FFs to zero.
This happens when the second AddLogContainer() of the malformed file is called, the pointer of the previous MyLogxxx is corrupted.
The problem occurs because the SignaturesOffset, which should be 0x50, is now 0xFFFF0050, so it allows writing out of bounds in the memset that follows.
Corrupting the “pContainer” pointer:
The memset() function is going to corrupt the _CLFS_CONTAINER_CONTEXT structure that is below, this structure corresponds to the MyLogxxx file, since when were created, it located them 0x11000 bytes away from each other.
This way, it calculates exactly where to write to the next structure and zeroes out the top of the pointer, so it points to the user heap where the HeapSspray was created.
the base block structure of the malformed file is just 0x11000 before that of the MyLogxxx file.
Malformed:
MyLogxxx
RCX is smaller than RDX since 0xFFFF0050 was added to, instead of 0x50 as it should be.
and we got to the memset() function, to set the amount of 0xb0 bytes with Zeroes, with RCX pointing to the CLFS_CONTAINER_CONTEXT structure of the MyLogxxx file, specifically to the pContainer five high bytes.
This pointer Will be corrupted by overwriting the first bytes:
remaining pointing to a memory address previously controlled by us through HeapSpray
Then, the handle of the MyLogxxx file will be closed, and reaches the CClfsBaseFilePersisted::RemoveContainer, the vulnerability finally is triggered.
Revisiting the Patch
Now that we have more information, we notice that here it reads the Base_Block.LOG_BLOCK_HEADER.SignaturesOffset and the Base_Block. .LOG_BLOCK_HEADER.TotalSectorCount
In the first part of the patch that SignaturesOffset should not be greater than 0x7a00, in ours it was originally 0x50, if it arrived with a value greater than 0x7a00 it would throw us out.
Running the PoC in the patched machine, it compares 0x50 with 0x7a00 and since it is smaller it continues.
In the following block, the malformed cbSymbolZone is added to the value of the final address of _CLFS_BASE_RECORD_HEADER and this sum is stored in result_1.
Then, the address of the Base_Block is added with the SignatureOffset value, which in a normal file is 0x7980.
The maximum address of the base_block is 0x7a00, now the SymbolZone is allowed up to 0x80 before the limit.
It will store it in result_2, that is, that would be the maximum limit for the SymbolZone inside the base block, then it compares both results if the first is greater than the second, it means that it went out of bounds.
Obviously the first member will be bigger than the second and it will not continue, since the first sum of the cbSymbolZone + final address of the _CLFS_BASE_RECORD_HEADER exceeds the limit (which is the result_2) and leads in an “out of bounds”.
Corrupting the SignatureOffset
The last thing we would have to figure out is where the SignatureOffset value of 0x50 becomes 0xFFFF0050.
So, let's start over, reboot and stop at CLFS!CClfsBaseFilePersisted::LoadContainerQ where the value has not yet been changed in memory and still is 0x50.
Set an access breakpoint at offset 0x68 in SignatureOffset.
And after several stops, we detect the right moment when it modifies the value, in the ClfsEncodeBlockPrivate.
This function is not patched, so it could be a behavior caused by the low value of 0x50 and the rest of the values being manipulated.
Among the crafted values, we can see the ccoffsetArray value whose name in the _CLFS_BASE_RECORD_HEADER structure is rgClients and represents the array of offsets that point to the Client Context Object.
rgClients field is located at offset 0x138 (0x9a8-0x800-0x70) of the _CLFS_BASE_RECORD_HEADER structure.
In the PoC, this value is malformed to point a fake client context object, called FakeClientContext
This is the Client Context structure _CLFS_CLIENT_CONTEXT
struct _CLFS_CLIENT_CONTEXT
{
CLFS_NODE_ID cidNode;
CLFS_CLIENT_ID cidClient;
USHORT fAttributes;
ULONG cbFlushThreshold;
ULONG cShadowSectors;
ULONGLONG cbUndoCommitment;
LARGE_INTEGER llCreateTime;
LARGE_INTEGER llAccessTime;
LARGE_INTEGER llWriteTime;
CLFS_LSN lsnOwnerPage;
CLFS_LSN lsnArchiveTail;
CLFS_LSN lsnBase;
CLFS_LSN lsnLast;
CLFS_LSN lsnRestart;
CLFS_LSN lsnPhysicalBase;
CLFS_LSN lsnUnused1;
CLFS_LSN lsnUnused2;
CLFS_LOG_STATE eState;
union
{
HANDLE hSecurityContext;
ULONGLONG ullAlignment;
};
};
The eState value is in offset 0x78 from the start of the structure, in the crafted file 0x23a0+0x78.
This value shows the status of the log.
typedef UCHAR CLFS_LOG_STATE, *PCLFS_LOG_STATE;
const CLFS_LOG_STATE CLFS_LOG_UNINITIALIZED = 0x01;
const CLFS_LOG_STATE CLFS_LOG_INITIALIZED = 0x02;
const CLFS_LOG_STATE CLFS_LOG_ACTIVE = 0x04;
const CLFS_LOG_STATE CLFS_LOG_PENDING_DELETE = 0x08;
const CLFS_LOG_STATE CLFS_LOG_PENDING_ARCHIVE = 0x10;
const CLFS_LOG_STATE CLFS_LOG_SHUTDOWN = 0x20;
const CLFS_LOG_STATE CLFS_LOG_MULTIPLEXED = 0x40;
const CLFS_LOG_STATE CLFS_LOG_SECURE = 0x80;
this value is set to CLFS_LOG_STATE CLFS_LOG_SHUTDOWN =0x20
The other malformed value is fAttributes which corresponds to the set of FILE_ATTRIBUTE flags associated with the base log file (such as System and Hidden).
Since the field starts a byte earlier at 0xa and spans two bytes, the value of fAttributes is 0x100.
Finally, there is the blocknameoffset value that points to the offset 0x1bb8, I mean, by adding 0x78 and 0x800 points to the offset 0x2428 of the file.
Note that the offset to the Client Context is 0x1b30
So, the Client Context is in offset 0x23a0.
And just 0x10 before, it is the value corresponding to blocknameoffset.
Which would point to the string with the name
the last one is the blockattributeoffset which is 0xC before the Client Context at 0x2394.
These last two values belong to a structure prior to the Client Context of 0x30 bytes long, called**_CLFSHASHSYM**
typedef struct _CLFSHASHSYM
{
CLFS_NODE_ID cidNode;
ULONG ulHash;
ULONG cbHash;
ULONGLONG ulBelow;
ULONGLONG ulAbove;
LONG cbSymName;
LONG cbOffset;
BOOLEAN fDeleted;
} CLFSHASHSYM, *PCLFSHASHSYM;
they are at 0x20 and 0x24 bytes from the beginning of the _CLFSHASHSYM structure, so in the _CLFSHASHSYM structure the value called blockNameOffset in the POC is the cbSymName field and the blockAttributteoffset is the cbOffset field.
Those are the malformed values, now we need to see how they affect to change our SignaturesOffset from 0x50 value to 0xFFFF0050.
Let’s take a look at the CClfsBaseFile::AcquireClientContext() function, which should return the client context.
it calls the CClfsBaseFile::GetSymbol with the fourth argument which will be _CLFS_CLIENT_CONTEXT ** where it will store the pointer to Client Context.
Inside the CClfsBaseFile::GetSymbol function we pass the malformed ccoffsetArray offset to CClfsBaseFile::OffsetToAddr and get the address of the client context, let’s set a breakpoint there so it’ll stop when calling the file created with CreatelogFile .
There it is stopped with the ccoffsetArray crafted argument.
The CClfsBaseFile::OffsetToAddr function returns the false Client Context
And checks that the value of cbOffset is not zero since 0xC is found before the _CLFS_CLIENT_CONTEXT structure that is in RAX.
Then It compares the cbOffset with the **ccoffsetArray (**which is in RSI), they must be equal, otherwise we’ll get an error.
It also checks that cbSymName be equal to cbOffset+0x88, if not we’ll get an error too.
And finally, It compares the cidClient byte with zero
If all those checks are successful, the client context will be saved.
The output of function r14 points to Client Context
When exiting from CClfsLogFcbPhysical::Initialize we'll have the address of CLFS_CLIENT_CONTEXT.
Now It reads the value of fAttributes (0x100)
this function belongs to the class CClfsLogFcbPhysical
Which was allocated here, and its size is 0x15d0 and its tag is “ClfC”
Let’s create a structure to store what we are reversing, we’ll call it: struct_CClfsLogFcbPhysical.
Note that at 0x2b0 it saves the address of the CClfsBaseFilePersisted structure.
After saving many values in the structure, it goes to an important part, it tests the eState with 0x20.
Since the crafted value was 0x20, the test will return 1.
We see that in the constructor in the vtable is
It will check if the file is multiplexed.
So, it goes by the desired path, reaching CClfsLogFcbPhysical::ResetLog.
Several fields are initialized to zero except one that is initialized to 0xFFFFFFFF00000000.
Here retrieves the Client Context
it stores the value 0xFFFFFFFF00000000.
It writes 0xFFFFFFFF is offset 0x5c which is the high part of CLFS_LSN lsnRestart.ullOffset
Now we execute the ClfsEncodeBlockPrivate() function, which is the responsible to overwrites the 0x50 with 0xFFFF0050 as we have seen before.
There it reads the value of SignatureOffset = 0x50 which is still as we put it in the malformed file and adds it to the start of CLFS_LOG_BLOCK_HEADER.
this is a loop that is writing 2 bytes, like the SignatureOffset instead of pointing to a correct value that in a normal file is a high value, for example 0x3f8 which makes it to write more forward, here it will write in the same CLFS_LOG_BLOCK_HEADER
The idea is to change the write destination to try to corrupt the SignatureOffset value.
Normal File
At this point, it will start to loop and write two bytes.
The counter must reach the value 0x3d to exit the loop.
RCX is increasing from 0x200, we are already in the third cycle, and its value is 0x600
in the iteration 0xe, RCX is 0x1a00
That was where he had written the 0xFFFFFFFF000000.
It’s reading the last two bytes FFFF
And it’ll copy then in R8
As we've seen, this value is critical as it allows you to bypass the check and write out of bounds to corrupt the pContainer pointer of the file that follows the memset() and write zeros at the top and leave it pointing to our controlled memory (HeapSpray).
In the CClfsBaseFilePersisted::AllocSymbol that the same sum that is going to get the destination of the memset which is cbSymbolZone + final address of CLFS_BASE_RECORD_HEADER compares it before against Base_block + 0xFFFF0050, so it has corrupted values on both sides of the equation.
CbSymbolZone= 0x1114B
It is the malformed value that added to the final address of CLFS_BASE_RECORD_HEADER will make it write out of bounds and the other member of the comparison that should be the address of the Base Block + SignatureOffset, remains SignatureOffset =0xFFFF0050 which allows this check to pass and write out of bounds in the memset() and zero the top of the pointer that will remain pointing to our HeapSpray.
Since RCX is smaller than RDX.
As we have seen before. (Values may differ because they belong to a previous execution)
It will corrupt the pointer, setting the highest bytes to 0
Leaving it pointing to a memory area that we control through HeapSpray
So, when the vulnerability is triggered, we get to CClfsBaseFilePersisted::RemoveContainer
There will be the already corrupt pointer and it can be exploited as we saw previously.
At this point we have bug exploited, it leads to control the functions that allows to read the SYSTEM token and write in our own process to achieve the local privilege escalation.
We hope you find it useful, if you have any doubt can contact us at Ricardo.narvaja@fortra.com and Esteban.kazimiro@fortra.com
Enjoy!