CVE-2019-0717
CVE-2019-0717 :Microsoft Hyper-V虚拟网络交换机VmsMpCommonPvtSetRequestCommon越界读取
Hyper-V依靠名为Virtual Network Switch的组件为虚拟机提供各种联网服务。虚拟网络交换机(vmswitch.sys)是驻留在根分区内核中的符合RNDIS的虚拟设备。它作为半虚拟化虚拟以太网控制器直接暴露给第2代VM,在第1代VM中,它用作模拟DEC以太网控制器的后端而被间接利用。在所有情况下,从提供Internet连接和虚拟LAN到虚拟机,再到将所有内容桥接到主机上的物理以太网适配器,vmswitch都是Hyper-V云中所有网络背后的支柱。
第2代VM通过在VMBUS上发送RNDIS协议数据和网络流直接与vmswitch对话。根分区中的vmswitch.sys模块侦听Windows上DPC线程中VMBUS上的数据可用性,而该可用性将由VM生成的综合中断唤醒。然后,对VM提供的RNDIS协议数据进行解析和调度,以在虚拟设备的各个子系统中进行处理。
当vmswitch收到Set类型的RNDIS消息时,经过一系列数据清理之后,将最终调用VmsMpCommonPvtSetRequestCommon()过程进行处理。在VmsMpCommonPvtSetRequestCommon内部,一个特定的路径负责处理带有OID RNDIS_OID_GEN_RNDIS_CONFIG_PARAMETER的RNDIS设置请求:
.text:00000001C001FB07 loc_1C001FB07: ; CODE XREF: VmsMpCommonPvtSetRequestCommon+D0↑j
.text:00000001C001FB07 movups xmm0, xmmword ptr [r9]
.text:00000001C001FB0B mov r12d, [r9+10h]
.text:00000001C001FB0F mov [rbp+var_10], r12d
.text:00000001C001FB13 movd edx, xmm0
.text:00000001C001FB17 movups [rbp+arg_offset_copy2], xmm0
.text:00000001C001FB1B cmp edi, edx ; size < parameter_name_offset ?
.text:00000001C001FB1D jb @@error
.text:00000001C001FB23 mov rcx, qword ptr [rbp+arg_offset_copy2]
.text:00000001C001FB27 mov eax, edi
.text:00000001C001FB29 shr rcx, 20h
.text:00000001C001FB2D sub eax, edx
.text:00000001C001FB2F cmp eax, ecx ; size - parameter_name_offset < parameter_name_length ?
.text:00000001C001FB31 jb @@error
.text:00000001C001FB37 mov rcx, qword ptr [rbp+arg_offset_copy2+8]
.text:00000001C001FB3B shr rcx, 20h
.text:00000001C001FB3F cmp edi, ecx ; size < parameter_value_offset ?
.text:00000001C001FB41 jb @@error2
.text:00000001C001FB47 mov eax, edi
.text:00000001C001FB49 sub eax, ecx
.text:00000001C001FB4B cmp eax, r12d ; size - parameter_value_offset < parameter_value_length ?
.text:00000001C001FB4E jb @@error2
.text:00000001C001FB54 mov r15d, edx
.text:00000001C001FB57 lea r13, [r9+rcx]
.text:00000001C001FB5B add r15, r9
.text:00000001C001FB5E lea rcx, aNetworkaddress ; "NetworkAddress"
.text:00000001C001FB65 mov rdx, r15 ; Buf2
.text:00000001C001FB68 mov r8d, 1Ch ; Size
.text:00000001C001FB6E call memcmp
在以上代码片段的开头,$ r9寄存器指向rndis_config_parameter_info类型的InformationBuffer:
/ * Linux集成服务* /
/ *在OID的SetRequest中传递的信息缓冲区的格式* /
/ * OID_GEN_RNDIS_CONFIG_PARAMETER。 * /
struct rndis_config_parameter_info {
u32 parameter_name_offset;
u32 parameter_name_length;
u32 parameter_type;
u32 parameter_value_offset;
u32 parameter_value_length;
};
此数据的内容和长度由VM完全控制。
上面的代码片段中的四项检查正确地验证了rndis_config_parameter_info成员提供的数据偏移量是否在请求的范围内。但是,有一个窄边情况无法验证。当在静态长度值为0x1c的00000001C001FB6E处最终调用memcmp()时,$ r15指向VM控制的parameter_name值,该值可以小于0x1c。如果parameter_name小于0x1c,并且也落在与未分配空间相邻的已分配内存页的末尾,则根分区OS将由于读取访问冲突而进行错误检查。
此错误的潜在影响是整个Hyper-V云的持久性DoS。利用起来并不容易,必须专门整理堆,才能在没有专门的调试工具的情况下使易受攻击的Hyper-V主机崩溃。
开发注意事项
从理论上讲,有可能在未启用驱动程序验证程序的情况下利用此问题,并在任意来宾操作系统和默认配置下的Hyper-V根分区操作系统中导致持久性DoS。
首先,请注意,来宾VM对vmswitch中的内存管理有很大程度的控制。例如,考虑故障存储器上!verifier的输出:
1: kd> !verifier 80 r9
...
======================================================================
Pool block ffffd90f1b0f2fa0, Size 0000000000000060, Thread ffffd90f189d5080
fffff8005d74ee0d nt!VfAllocPoolNotification+0x31
fffff8005d73c21f nt!VeAllocatePoolWithTagPriority+0x2cf
fffff8005d74a6b8 nt!XdvExAllocatePoolInternal+0x18
fffff8005d73c6b7 nt!VerifierExAllocatePoolWithTag+0x87
fffff8005fd2949a vmswitch!RndisDevHostDispatchControlMessage+0x72
fffff8005fd28c26 vmswitch!VmsVmNicPvtKmclProcessingComplete+0x156
fffff808e58727a5 VmsProxy!VmsProxyVmNicPvtKmclProcessingComplete+0x15
fffff808e5882772 vmbkmclr!InpFillAndProcessQueue+0x242
fffff808e588243c vmbkmclr!KmclpVmbusIsr+0x13c
fffff8005fc610b0 vmbusr!ParentRingInterruptDpc+0xa0
fffff8005cecfc67 nt!KiExecuteAllDpcs+0x2e7
fffff8005cecf2ae nt!KiRetireDpcList+0x1ae
fffff8005cfd1445 nt!KxRetireDpcList+0x5
RndisDevHostDispatchControlMessage:
.text:00000001C0039485 movsxd rdx, edi ; NumberOfBytes
.text:00000001C0039488 mov ecx, 200h ; PoolType
.text:00000001C003948D mov r8d, 44527356h ; Tag
.text:00000001C0039493 call cs:__imp_ExAllocatePoolWithTag
.text:00000001C003949A nop dword ptr [rax+rax+00h]
.text:00000001C003949F mov rbp, rax
.text:00000001C00394A2 test rax, rax
.text:00000001C00394A5 jz loc_1C0069E31
.text:00000001C00394AB mov rax, [r15]
.text:00000001C00394AE mov rdx, r12 ; Src
.text:00000001C00394B1 mov ecx, [rax+28h]
.text:00000001C00394B4 mov [rbp+10h], ecx
.text:00000001C00394B7 mov r8d, ecx ; Size
.text:00000001C00394BA lea rcx, [rbp+14h] ; Dst
.text:00000001C00394BE call memmove
分配回溯中的RndisDevHostDispatchControlMessage是分派来自来宾的RNDIS请求的顶级功能。对于每个传入的请求,它都会根据来宾VM提供的请求大小分配内存。这样,来宾VM既可以控制vmswitch中的时序,也可以控制内存分配的大小,这有助于进行堆整理。
尚不清楚Guest VM是否对释放内存具有相同程度的控制。 vmswitch完成处理请求后,将释放为该请求分配的内存。但是,通过利用某些RNDIS请求可能比其他请求花费更长的时间这一事实,可以(至少)综合构造free()原语。
利用漏洞的一般思路是创建两种类型的内存页的交替模式:一种经过修饰,以使我们的恶意请求成为内存页中的最后一个字节序列;另一个是免费的,或者可能由VM释放。
通过首先发送许多适当大小的小型RNDIS请求,刷新Windows内核中的后备列表和自由列表,可以设计出类型1页面;这将触发分配新的内存页面;然后以可控的方式占用少量分配来占据新页面。
由于攻击者对内存释放的控制的限制和KASLR缓解的限制,第2类页面的构建似乎比较棘手。但是,由于KASLR,在某些情况下,我希望在类型0页面之后自然会发生未分配的内存页面。
主机BSOD重启后,Guest VM将自动启动,并再次运行漏洞利用程序。因此,可以实现Hyper-V云的持久DoS。