[2021]微软如何检测到hypervisor以及如何预防 huoji PG,hypervisor,微软 2021-05-13 1453 次浏览 1 次点赞 微软挺奇怪的,什么事都要管一腿.总所周知 win 1809后hypervisor的一些功能比如msr hook(通过替换msr_lstar寄存器)的方案已经无了.怎么无的呢?除了kva shadow的问题,还有如下几个问题: 翻开微软的内核,有如下函数 KiErrata361Present KiErrataSkx55Present KiErrata704Present ... 这些函数有如下特点: 1. 名字莫名其妙 2. 调用者也莫名其妙,比如KiErrata361Present在一个IDA分析都要半个小时的函数里面调用. 3. 大部分都是微软检测虚拟机的函数 KiErrata704Present: 他长这样: <!--more--> ```cpp asm_pg_KiErrata704Present proc mov ecx, 0C0000084h rdmsr push rdx push rax and eax, 0FFFFFEFFh wrmsr pushfq or qword ptr[rsp], 100h popfq syscall ; Low latency system call mov r10, rcx mov ecx, 0C0000084h pop rax pop rdx wrmsr mov rax, r10 ret asm_pg_KiErrata704Present endp ``` 让我们简单的说一下,这个函数首先保存FMASK的值，然后设置MSR值，以便SYSCALL操作不会修改TF.然后修改TF位.让下一步指令单步执行(#DB异常),DB异常后果就是如果你hook了lstar,断点就打在了你的kisystemcall64上了.你的位置会被直接暴露.然后就是蓝屏(蓝屏代码在系统的DB异常处理函数里) 解决方案也很简单,设置DB异常退出,发现RIP == 我的kisystemcall64直接TF设置为0然后转到系统的kisystemcall64就行,代码如下: ```cpp if (interruption_type == ia32_hardware_exception && guest_status->rip == (uintptr_t)fake_kisystemcall64) { /* KiErrataSkx55Present */ DebugPrint("KiErrataSkx55Present Detected \n"); guest_status->rip = _huoji_readmsr(ia32_lstar); guest_status->eflags.Fields.TF = 0; _huoji_vmx_vmwrite(guest_rip, guest_status->rip); return; //return adjust_rip(guest_status); } ``` 但是这没完,继续看 KiErrata361Present: 他长这样: ```cpp asm_pg_KiErrata361Present proc mov ax,ss pushfq or qword ptr[rsp],100h popfq mov ss,ax db 0f1h ;icebp pushfq and qword ptr[rsp],0FFFFFEFFh popfq ret asm_pg_KiErrata361Present endp ``` 简单说明一下,icebp这个指令是intel的一个奇葩,他在intel是会走DB异常的,而且会要求CPU优先处理他的异常(因为他的type是ia32_prisw_exception,比普通的DB异常高一级).但是如果他跟mov ss结合在一起呢? 看我的CVE-2018-8897学习笔记: https://key08.com/index.php/2021/03/13/968.html mov ss会产生一个异常，但是这个异常会在下一个指令执行的时候再抛出.因此 他首先mov ss了,这样下一个指令才会执行异常, 到icebp的时候, mov ss造成的异常就应该被抛出了。但是同时icebp也会造成一个异常，而且异常优先级哎比mov ss的高,你说巧不巧.这样CPU就会处理icebp的异常而不处理mov ss的异常，但是mov ss的异常是必须要求dr6的single_instruction bit位(也就叫做DR6.BS位)为1的,要不然就炸。很遗憾的是icebp的异常他不会设置这个bs位,导致直接炸虚拟机.很多时候虚拟机在2004跑起来了结果一阵子就虚拟机guest机异常了就是这个毛病 解决方案就是看到有TF设置的直接给dr6.bs设置为1就行,代码如下: ```cpp if (interruption_type == ia32_prisw_exception) { /* KiErrata361Present */ _debug_dr6 dr6_register = { static_cast<ULONG32>(guest_status->guest_context->Dr6) }; DebugPrint("KiErrata361Present Detected Rip: %p tf %d dr6 %d \n", guest_status->rip, guest_status->eflags.Fields.TF, dr6_register.single_instruction); if (guest_status->eflags.Fields.TF) { DebugPrint("KiErrata361Present guest_status->eflags.Fields.TF \n"); //guest_status->guest_context->Dr6 = (1UL << 6); ////BS位置1 dr6_register.single_instruction = 1; guest_status->guest_context->Dr6 = dr6_register.flags; //guest_status->eflags.Fields.TF = 0; inject_event(guest_status, ia32_debug_exception, interruption_type, false, NULL, NULL); return; } } ``` KiErrataSkx55Present: 代码如下: ```cpp asm_pg_KiErrataSkx55Present proc mov ss, word ptr [rcx] syscall mov rax, rcx ret asm_pg_KiErrataSkx55Present endp ``` 这个跟CVE-2018-8897大同小异,如前面所说,mov ss造成的异常会在syscall的地方执行,syscall会跑到你的kisystemcall64的地址,解决方法也一样,发现有异常在你的kisystemcall64上TF位置0改RIP到原版本的lstar上即可.不再做阐述 本文由 huoji 创作，采用 知识共享署名 3.0，可自由转载、引用，但需署名作者且注明文章出处。 点赞 1
请注意,icebp指令在amd是不起作用的，因为amd有单独的退出事件。也就是说amd完全不用管icebp指令带来的问题。amd yes