2.从用户物理地址转换到QEMU假造地址空间。实验中，我们需要添加假造结构并得到它们在QEMU假造地址空间中的准确地址。在x64系统中，一个假造地址由一个页地址（0-11位）和一个页号构成。在linux系统中，pagemap文件答应有CAP_SYS_ADMIN特权的用户空间进程发现每个假造页映射到哪个物理框架。为了便于在内核中记录，pagemap文件包含了每个假造页的一个64位的值。参考文章[5]：为了将假造地址转换成物理地址，我们使用Nelson Elhage的代码[3]。下面的步伐分配了一段缓冲区，用字符串“Where am I?”填充并打印其物理地址：
案例一（利用一个堆溢出毛病实现VMware假造机逃逸）
1. 介绍2017年3月，长亭安全研究实验室（Chaitin Security Research Lab）参加了Pwn2Own黑客大赛，我作为团队的一员，一直专注于VMware Workstation Pro的破解，并成功在赛前完成了一个假造机逃逸的毛病利用。（很不）幸运的是，就在Pwn2Own比赛的前一天（3月14日），VMware发布了一个新的版本，其中修复了我们所利用的毛病。在本文中，我会介绍我们从发现毛病到完成利用的整个过程。感谢@kelwin在实现毛病利用过程中给予的帮助，也感谢ZDI的朋友，他们近期也发布了一篇相关博客，正是这篇博文促使我们完成本篇writeup。本文主要由三部门组成：起首我们会扼要介绍VMware中的RPCI机制，其次我们会描述本文使用的毛病，末了讲解我们是如何利用这一个毛病来绕过ASLR并实当代码执行的。
2. VMware RPCI机制VMware实现了多种假造机（下文称为guest）与宿主机（下文称文host）之间的通信方式。其中一种方式是通过一个叫做Backdoor的接口，这种方式的设计很风趣，guest只需在用户态就可以通过该接口发送下令。VMware Tools也部门使用了这种接口来和host通信。我们来看部门相关代码（摘自open-vm-tools中的lib/backdoor/backdoorGcc64.c）：
void Backdoor_InOut(Backdoor_proto *myBp) // IN/OUT { uint64 dummy; __asm__ __volatile__(#ifdef __APPLE__ /* * Save %rbx on the stack because the Mac OS GCC doesn't want us to * clobber it - it erroneously thinks %rbx is the PIC register. * (Radar bug 7304232) */ "pushq %%rbx" "\n\t"#endif "pushq %%rax" "\n\t" "movq 40(%%rax), %%rdi" "\n\t" "movq 32(%%rax), %%rsi" "\n\t" "movq 24(%%rax), %%rdx" "\n\t" "movq 16(%%rax), %%rcx" "\n\t" "movq 8(%%rax), %%rbx" "\n\t" "movq (%%rax), %%rax" "\n\t" "inl %%dx, %%eax" "\n\t" /* NB: There is no inq instruction */ "xchgq %%rax, (%%rsp)" "\n\t" "movq %%rdi, 40(%%rax)" "\n\t" "movq %%rsi, 32(%%rax)" "\n\t" "movq %%rdx, 24(%%rax)" "\n\t" "movq %%rcx, 16(%%rax)" "\n\t" "movq %%rbx, 8(%%rax)" "\n\t" "popq (%%rax)" "\n\t"#ifdef __APPLE__ "popq %%rbx" "\n\t"#endif : "=a" (dummy) : "0" (myBp) /* * vmware can modify the whole VM state without the compiler knowing * it. So far it does not modify EFLAGS. --hpreg */ :#ifndef __APPLE__ /* %rbx is unchanged at the end of the function on Mac OS. */ "rbx",#endif "rcx", "rdx", "rsi", "rdi", "memory" );}上面的代码中出现了一个很奇怪的指令inl。在通常环境下（比方Linux下默认的I/O权限设置），用户态步伐是无法执行I/O指令的，因为这条指令只会让用户态步伐堕落并产生崩溃。而此处这条指令产生的权限错误会被host上的hypervisor捕捉，从而实现通信。Backdoor所引入的这种从guest上的用户态步伐直接和host通信的能力，带来了一个风趣的攻击面，这个攻击面正好满足Pwn2Own的要求：“在这个类型（指假造机逃逸这一类挑衅）中，攻击必须从guest的非管理员帐号发起，并实现在host操作系统中执行恣意代码”。guest将0x564D5868存入$eax，I/O端标语0x5658或0x5659存储在$dx中，分别对应低带宽和高带宽通信。别的寄存器被用于传递参数，比方$ecx的低16位被用来存储下令号。对于RPCI通信，下令号会被设为BDOOR_CMD_MESSAGE（=30）。文件lib/include/backdoor_def.h中包含了一些支持的backdoor下令列表。host捕捉到错误后，会读取下令号并分发至相应的处理函数。此处我省略了很多细节，如果你有兴趣可以阅读相关源码。
2.1 RPCI远程过程调用接口RPCI（Remote Procedure Call Interface）是基于前面提到的Backdoor机制实现的。依赖这个机制，guest能够向host发送请求来完成某些操作，比方，拖放（Drag n Drop）/复制粘贴（Copy Paste）操作、发送或获取信息等等。RPCI请求的格式非常简单： 。比方RPCI请求info-get guestinfo.ip可以用来获取guest的IP地址。对于每个RPCI下令，在vmware-vmx进程中都有相关注册和处理操作。需要注意的是有些RPCI下令是基于VMCI套接字实现的，但此内容已超出本文讨论的范畴。
3. 毛病花了一些时间逆向各种不同的RPCI处理函数之后，我决定专注于分析拖放（Drag n Drop，下面简称为DnD）和复制粘贴（Copy Paste，下面简称为CP）功能。这部门可能是最复杂的RPCI下令，也是最可能找到毛病的地方。在深入理解的DnD/CP内部工作机理后，可以很容易发现，在没有用户交互的情况下，这些处理函数中的许多功能是无法调用的。DnD/CP的核心功能维护了一个状态机，在无用户交互（比方拖动鼠标从host到guest中）情况下，许多状态是无法到达的。我决定看一看Pwnfest 2016上被利用的毛病，该毛病在这个VMware安全公告中有所提及。此时我的idb已经标上了很多符号，所以很容易就通过bindiff找到了补丁的位置。下面的代码是修补之前存在毛病的函数（可以看出services/plugins/dndcp/dnddndCPMsgV4.c中有对应源码，毛病依然存在于open-vm-tools的git堆栈的master分支当中）：
static Bool DnDCPMsgV4IsPacketValid(const uint8 *packet, size_t packetSize){ DnDCPMsgHdrV4 *msgHdr = NULL; ASSERT(packet); if (packetSize < DND_CP_MSG_HEADERSIZE_V4) { return FALSE; } msgHdr = (DnDCPMsgHdrV4 *)packet; /* Payload size is not valid. */ if (msgHdr->payloadSize > DND_CP_PACKET_MAX_PAYLOAD_SIZE_V4) { return FALSE; } /* Binary size is not valid. */ if (msgHdr->binarySize > DND_CP_MSG_MAX_BINARY_SIZE_V4) { return FALSE; } /* Payload size is more than binary size. */ if (msgHdr->payloadOffset + msgHdr->payloadSize > msgHdr->binarySize) { // [1]每个包的binarySize可以手动设置，但是步伐默认为不修改。 return FALSE; } return TRUE;}Bool DnDCPMsgV4_UnserializeMultiple(DnDCPMsgV4 *msg, const uint8 *packet, size_t packetSize){ DnDCPMsgHdrV4 *msgHdr = NULL; ASSERT(msg); ASSERT(packet); if (!DnDCPMsgV4IsPacketValid(packet, packetSize)) {//检查长度 return FALSE; } msgHdr = (DnDCPMsgHdrV4 *)packet; /* * For each session, there is at most 1 big message. If the received * sessionId is different with buffered one, the received packet is for * another another new message. Destroy old buffered message. */ if (msg->binary && msg->hdr.sessionId != msgHdr->sessionId) { DnDCPMsgV4_Destroy(msg); } /* Offset should be 0 for new message. */ if (NULL == msg->binary && msgHdr->payloadOffset != 0) { return FALSE; } /* For existing buffered message, the payload offset should match. */ if (msg->binary && msg->hdr.sessionId == msgHdr->sessionId && msg->hdr.payloadOffset != msgHdr->payloadOffset) { return FALSE; } if (NULL == msg->binary) { memcpy(msg, msgHdr, DND_CP_MSG_HEADERSIZE_V4); msg->binary = Util_SafeMalloc(msg->hdr.binarySize);//以第一次设置的长度分配空间 } /* msg->hdr.payloadOffset is used as received binary size. */ memcpy(msg->binary + msg->hdr.payloadOffset, packet + DND_CP_MSG_HEADERSIZE_V4, msgHdr->payloadSize); // [2].void *memcpy(void *dest, const void *src, size_t n); msg->hdr.payloadOffset += msgHdr->payloadSize; return TRUE;}对于Version 4的DnD/CP功能，当guest发送分片DnD/CP下令数据包时，host会调用上面的函数来重组guest发送的DnD/CP消息。接收的第一个包必须满足payloadOffset为0，binarySize代表堆上分配的buffer长度。[1]处的检查比较了包头中的binarySize，用来确保payloadOffset和payloadSize不会越界。在[2]处，数据会被拷入分配的buffer中。但是[1]处的检查存在问题，它只对接收的第一个包有用，对于后续的数据包，这个检查是无效的，因为代码预期包头中的binarySize和分片流中的第一个包相同，但实际上你可以在后续的包中指定更大的binarySize来满足检查，并触发堆溢出。所以，该毛病可以通过发送下面的两个分片来触发：
packet 1{ ... binarySize = 0x100 payloadOffset = 0 payloadSize = 0x50 sessionId = 0x41414141 ... #...0x50 bytes...#}packet 2{ ... binarySize = 0x1000 payloadOffset = 0x50 payloadSize = 0x100 sessionId = 0x41414141 ... #...0x100 bytes...#}有了以上的知识，我决定看看Version 3中的DnD/CP功能中是不是也存在类似的问题。令人惊奇的是，几乎相同的毛病存在于Version 3的代码中（这个毛病最初通过逆向分析来发现，但是我们后来意识到v3的代码也在open-vm-tools的git堆栈中）：
Bool DnD_TransportBufAppendPacket(DnDTransportBuffer *buf, // IN/OUT DnDTransportPacketHeader *packet, // IN size_t packetSize) // IN{ ASSERT(buf); ASSERT(packetSize == (packet->payloadSize + DND_TRANSPORT_PACKET_HEADER_SIZE) && packetSize payloadSize + packet->offset) totalSize && packet->totalSize payloadSize + DND_TRANSPORT_PACKET_HEADER_SIZE) || packetSize > DND_MAX_TRANSPORT_PACKET_SIZE || (packet->payloadSize + packet->offset) > packet->totalSize || //[1] packet->totalSize > DNDMSG_MAX_ARGSZ) { goto error; } /* * If seqNum does not match, it means either this is the first packet, or there * is a timeout in another side. Reset the buffer in all cases. */ if (buf->seqNum != packet->seqNum) { DnD_TransportBufReset(buf); } if (!buf->buffer) { ASSERT(!packet->offset); if (packet->offset) { goto error; } buf->buffer = Util_SafeMalloc(packet->totalSize); buf->totalSize = packet->totalSize; buf->seqNum = packet->seqNum; buf->offset = 0; } if (buf->offset != packet->offset) { goto error; } memcpy(buf->buffer + buf->offset, packet->payload, packet->payloadSize); buf->offset += packet->payloadSize; return TRUE;error: DnD_TransportBufReset(buf); return FALSE;}Version 3的DnD/CP在分片重组时，上面的函数会被调用。此处我们可以在[1]处看到与之前相同的情况，代码依然假设后续分片中的totalSize会和第一个分片一致。因此这个毛病可以用和之前相同的方法触发：
packet 1{ ... totalSize = 0x100 payloadOffset = 0 payloadSize = 0x50 seqNum = 0x41414141 ... #...0x50 bytes...#}packet 2{ ... totalSize = 0x1000 payloadOffset = 0x50 payloadSize = 0x100 seqNum = 0x41414141 ... #...0x100 bytes...#}在Pwn2Own如许的比赛中，这个毛病是很弱的，因为它只是受到之前毛病的启发，而且甚至可以说是同一个。因此，如许的毛病在赛前被修补并不惊奇（好吧，也许我们并不希望这个毛病在比赛前一天被修复）。对应的VMware安全公告在这里。受到这个毛病影响的VMWare Workstation Pro最新版本是12.5.3。接下来，让我们看一看这个毛病是如何被用来完成从guest到host的逃逸的！
|Archiver|手机版|小黑屋|12558网页游戏私服论坛
|网站地图
发表于 2020-9-17 18:01:55
