This vulnerability allows local attackers to disclose sensitive information on affected installations of Oracle VirtualBox. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability.
The specific flaw exists within the VMSVGA virtual device. The issue results from an integer truncation before reading from memory. An attacker can leverage this in conjunction with other vulnerabilities to escalate privileges and execute arbitrary code in the context of the hypervisor.
I originally mentioned that this bug will be disclosed 3 months after the patch. However, I decided to release it today since 3 months seems to be too long... As long as there is an another researcher who disclosed his bugs at the patch date, it would be fine releasing this bug today.
High-level overview of the vulnerability and the possible effect of using it
A divide by zero vulnerability exists in vmsvga3dSurfaceDMA, in SVGA3D of Oracle VirtualBox 6.1.16 Linux distributions. To use this vulnerability, 3D acceleration option should be turned for a guest OS, and an attacker must get a root privilege in the guest OS.
This vulnerability allows local or remote attackers to crash VMs with 3D acceleration, leading to a denial-of-service condition. Flaws exist in three points: (1) Invalid surfaces can be defined in vmsvga3dSurfaceDefine, (2) Textures can be bound to invalid surfaces, (3) No check for divisor in vmsvga3dSurfaceDMA.
Exact product that was found to be vulnerable including complete version information
Version Information
Oracle VirtualBox 6.1.16 releases (which is the latest release in 2020/11/17) except for Windows are affected by this vulnerability. PoC code is tested with the release and Ubuntu 20.04.1 desktop for host and guest OSes, but it is also expected to work with other operating systems, except with Windows.
Precondition
An attacker must get a root privilege in a guest OS in order to use this vulnerability. Also, 3D acceleration option must be turned on for the guest OS to use this vulnerability. Finally, graphics controller option must be set to VMSVGA, which is the default option for Linux guest OSes.
Root Cause Analysis
Overview
A divide by zero vulnerability exists in vmsvga3dSurfaceDMA, which handles the SVGA_3D_CMD_SURFACE_DMA command in the SVGA FIFO loop. A VM crashes when the vulnerability is triggered, leading to the denial-of-service condition on the software. The vulnerability lies in the simple overflow check of the guest offset, before the offset gets verified by vmsvgaR3GmrTransfer. (See Code 1)
// Code 1
// Devices/Graphics/DevVGA-SVGA3d.cpp:610
/* srcx, srcy and srcz values are used to calculate the guest offset.
* The offset will be verified by vmsvgaR3GmrTransfer, so just check for overflows here.
*/
AssertReturn(srcz < UINT32_MAX / pMipLevel->mipmapSize.height / cbGuestPitch, VERR_INVALID_PARAMETER);
cbGuestPitch can be zero with forged surfaces, leading to a divide by zero vulnerability. No check exists for pMipLevel->cbSurfacePitch, so cbGuestPitch can be zero. AssertReturn function remains as an if-else statement in a release version, so the vulnerability exists in a release version.
Three steps are needed to reach the vulnerable condition. These steps each uses a bug contained in its process.
Two invalid surfaces, which have invalid mipmap sizes, are defined using a SVGA_3D_CMD_SURFACE_DEFINE command. One of two surfaces may be a valid surface. It doesn't affect the next step.
Textures are bound to two surfaces using SVGA_3D_CMD_SURFACE_STRETCHBLT command. Two surfaces are each sent as source and destination surfaces.
Divide by zero is triggered by using SVGA_3D_CMD_SURFACE_DMA command with guest.pitch = 0
Code flow from input to vmsvga* functions
Commands are asynchronously handled with the FIFO loop. (vmsvgaR3FifoLoop in Devices/Graphics/DevVGA-SVGA.cpp) Commands sent via VMware SVGA II PCI device are first enqueued to a SVGA command FIFO buffer, and they are dequeued and handled asynchronously in FIFO order by the loop.
Parsing and executing commands is done in vmsvgaR3FifoLoop function, which contains a simple switch-case statement to handle commands. With a given command id, the loop selects the method of parsing and handling the command. The loop eventually calls vmsvga~~ function to handle a command.
Step 1. Definition of invalid surfaces
Definition of an invalid surface is needed for to reach the vulnerable condition. Our goal is to make a surface that has the following conditions:
Mipmap size is not zero so the clip box is not considered as empty in DMA command.
cbSurfacePitch (derived from cBlocksX, cBlocksY, ...) is zero to trigger divide by zero.
Texture is bound to the surface so that oglId is not zero.
In this step, a surface is defined with a non-zero mipmap size and a zero cbSurfacePitch value. A surface should not be defined in this condition, so this can be considered as a bug.
Making an invalid surface is simple: a surface can be defined with a negative size. (i.e. (-1, -1, -1)) Then, the definition fails in the condition described below. (See Code 2)
cBlocksX becomes a negative value (i.e. -1), which is given as the argument of the command. cMaxBlocksX is 0x80000000 / n since cbMemRemaining remains 0x80000000 and pSurface->cbBlock becomes a small integer which is calculated from a given surface format. (i.e. 1, 2, 4, ..., see DevVGA-SVGA3d-shard.cpp:263 for details) Since the check is done with an unsigned comparison, cBlocksX is always bigger than cMaxBlocksX, so the check fails and the function returns.
A mipmap is already allocated before checking the validity of cBlocks, and the default value of a mipmap is zero for all other remaining values that are not initialized. Therefore, *cbSurfacePitch also becomes zero since it is not initialized. Mipmap size is already assigned before validation, so it is not zero. (See Code 3)
// Code 3
// Devices/Graphics/DevVGA-SVGA3d.cpp:223
for (uint32_t i=0; i < cMipLevels; i++)
pSurface->paMipmapLevels[i].mipmapSize = paMipLevelSizes[i];
The outcome of step 1 is an object that looks like below. (Size is given as (-1, -1, -1)) Note that mipmapSize is not zero, and cbSurfacePitch is zero.
Texture binding to the surface made in step 1 is needed to reach the vulnerable condition. In step 2, SVGA_3D_CMD_SURFACE_STRETCHBLT command is used to bind a texture. Draw primitive functions may be used to bind textures, but they are more complicated than vmsvga3dSurfaceStretchBlt function, so the function is used in step 2. Also, a buffer may be bound to a surface instead of binding a texture to it, but binding a texture is chosen because of the same reason.
vmsvga3dSurfaceStretchBlt needs two surfaces: one as a source surface and the other as a destination surface. One of two surfaces may be valid, but one of them must be the surface which is made in step 1 to exploit the vulnerability.
Codes described in Code 4 is used to create and bind the texture to the surfaces. Even if a surface is invalid, a texture will be created and bound to the surface. vmsvga3dBackCreateTexture function will create a texture and bind it to the surface.
// Code 4
// Devices/Graphics/DevVGA-SVGA3d.cpp:437
if (!VMSVGA3DSURFACE_HAS_HW_SURFACE(pSrcSurface))
{
/* Unknown surface type; turn it into a texture, which can be used for other purposes too. */
LogFunc(("unknown src sid=%u type=%d format=%d -> create texture\n", sidSrc, pSrcSurface->surfaceFlags, pSrcSurface->format));
rc = vmsvga3dBackCreateTexture(pState, pContext, pContext->id, pSrcSurface);
AssertRCReturn(rc, rc);
}
if (!VMSVGA3DSURFACE_HAS_HW_SURFACE(pDstSurface))
{
/* Unknown surface type; turn it into a texture, which can be used for other purposes too. */
LogFunc(("unknown dest sid=%u type=%d format=%d -> create texture\n", sidDst, pDstSurface->surfaceFlags, pDstSurface->format));
rc = vmsvga3dBackCreateTexture(pState, pContext, pContext->id, pDstSurface);
AssertRCReturn(rc, rc);
}
A texture should not be bound if a surface is invalid. Therefore, this can be also considered as a bug.
The outcome of step 2 is an object that looks like below. Note that oglId is not zero anymore.
Divide by zero bug in vmsvga3dSurfaceDMA can now be triggered with the surface made in step 1 and step 2. The problematic code is described in Code 5.
// Code 5
// Devices/Graphics/DevVGA-SVGA3d.cpp:610
/* srcx, srcy and srcz values are used to calculate the guest offset.
* The offset will be verified by vmsvgaR3GmrTransfer, so just check for overflows here.
*/
AssertReturn(srcz < UINT32_MAX / pMipLevel->mipmapSize.height / cbGuestPitch, VERR_INVALID_PARAMETER);
Here, divide by zero occurs when cbGuestPitch is zero. cbGuestPitch becomes zero if we give guest.pitch = 0. (guest.pitch is an argument of a DMA command given by the user) AssertReturn function remains as an if-else statement in a release version, so the vulnerability exists in a release version. See Code 6.
There are two checks that need to be bypassed to reach the vulnerable condition. One (Code 7) is bypassed by defining an invalid surface in step 1, and the other (Code 8) is bypassed by binding a texture to the invalid surface defined in step 2. The check in Code 7 requires a non-zero mipmap size, and the other check in Code 8 requires a non-zero oglId.
// Code 7
// Devices/Graphics/DevVGA-SVGA3d.cpp:536
/* The copybox's "dest" is coords in the host surface. Verify them against the surface's mipmap size. */
SVGA3dBox hostBox;
hostBox.x = paBoxes[i].x;
hostBox.y = paBoxes[i].y;
hostBox.z = paBoxes[i].z;
hostBox.w = paBoxes[i].w;
hostBox.h = paBoxes[i].h;
hostBox.d = paBoxes[i].d;
vmsvgaR3ClipBox(&pMipLevel->mipmapSize, &hostBox);
if ( !hostBox.w
|| !hostBox.h
|| !hostBox.d)
{
Log(("Skip empty box\n"));
continue;
}
// Devices/Graphics/DevVGA-SVGA.cpp:5274
/**
* Unsigned coordinates in pBox. Clip to [0; pSize).
*
* @param pSize Source surface dimensions.
* @param pBox Coordinates to be clipped.
*/
void vmsvgaR3ClipBox(const SVGA3dSize *pSize, SVGA3dBox *pBox)
{
/* x, w */
if (pBox->x > pSize->width)
pBox->x = pSize->width;
if (pBox->w > pSize->width - pBox->x)
pBox->w = pSize->width - pBox->x;
/* y, h */
if (pBox->y > pSize->height)
pBox->y = pSize->height;
if (pBox->h > pSize->height - pBox->y)
pBox->h = pSize->height - pBox->y;
/* z, d */
if (pBox->z > pSize->depth)
pBox->z = pSize->depth;
if (pBox->d > pSize->depth - pBox->z)
pBox->d = pSize->depth - pBox->z;
}
// Code 8
// Devices/Graphics/DevVGA-SVGA3d.cpp:504
if (!VMSVGA3DSURFACE_HAS_HW_SURFACE(pSurface))
{
/*
* Not realized in host hardware/library yet, we have to work with
* the copy of the data we've got in VMSVGA3DMIMAPLEVEL::pSurfaceData.
*/
AssertReturn(pMipLevel->pSurfaceData, VERR_INTERNAL_ERROR);
}
// Devices/Graphics/DevVGA-SVGA3d-internal.h:683 (VMSVGA3D_DIRECT3D not defined in linux release)
/** @def VMSVGA3DSURFACE_HAS_HW_SURFACE
* Checks whether the surface has a host hardware/library surface.
* @returns true/false
* @param a_pSurface The VMSVGA3d surface.
*/
#ifdef VMSVGA3D_DIRECT3D
# define VMSVGA3DSURFACE_HAS_HW_SURFACE(a_pSurface) ((a_pSurface)->u.pSurface != NULL)
#else
# define VMSVGA3DSURFACE_HAS_HW_SURFACE(a_pSurface) ((a_pSurface)->oglId.texture != OPENGL_INVALID_ID)
#endif
Vulnerable code can be reached by bypassing these two conditions. VM crashes with divide by zero, trying to divide with cbGuestPitch, which has zero value.
An invalid surface, which has a non-zero mipmap size and zero cBlocks* and cbSurfacePitch, can be defined.
A texture can be bound to an invalid surface.
No check for the divisor, which is cbGuestPitch, in DMA command.
Fixing this vulnerability depends on the design choice that developers make. There are two options to fix this vulnerability.
Deallocate the surface when defining a surface fails.
Validate mipmaps of surfaces whether they have proper fields whenever surfaces are used in commands. For this vulnerability, there are problems in vmsvga3dSurfaceStretchBlt, vmsvga3dBackCreateTexture, and vmsvga3dSurfaceDMA. However, other commands may also contain problems.
Proof-of-Concept
Environment
Proof-of-Concept code is tested on VirtualBox 6.1.16 version (recent version in 2020-11-20), Linux distribution. Version for host and guest OSes are Ubuntu 20.04.1 desktop, but other OSes except Windows are supposed to work as well. 3D acceleration under display option should be turned on, and graphics controller option should remain VMSVGA, which is the default setting for display in Linux distribution.
VirtualBox release can be downloaded in https://www.virtualbox.org/wiki/Downloads. Linux distribution needs to be downloaded for this vulnerability. (PoC code is tested on Ubuntu 20.04.1 desktop for guest and host OSes)
VirtualBox SVGA에서 버그를 하나 발견하여 벤더에 제보했고, CVE 번호를 하나 받게 되었다. 버그를 제보하고 CVE까지 받는 것은 처음인데, 내 이름이 패치 내역에 있는 것이 상당히 기분이 좋았다. 프로젝트로 진행해서 열심히 삽질하고 한 것이 나름대로 보상이 된 것 같다.
저 자료를 보면 VirtualBoBs 팀으로 버그가 3개가 들어가 있는데, 팀에서 벤더에 직접 제보하여 이번에 패치된 3건, ZDI 제보해서 오퍼까지 받은게 3건으로 총 6건을 발견하여 제보하였다. 버그 헌팅 처음 하는 사람들끼리 모여서 단기간에 으쌰으쌰해서 열심히 삽질한 것이 어떻게 성과가 잘 나온 것 같다. 처음에 VM 관련해서 아무런 지식이 없어 원데이로 삽질하고, CVE 훑어보고, 심지어는 방법론 자체를 공부하는 등 여러 삽질을 했다. 그럼에도 이런 활동들을 나름 계획을 세우고, 서로 자료 공유도 열심히 하고, 코로나 때문에 얼굴 한번 보지 못했어도 간단하게 인력 관리 봇 하나 구현해서 운영까지 해가며 어케어케 하다보니 프로젝트가 잘 된 것 같다.
버그에 대한 자세한 내용은 3달 정도 더 기다린 후에 공개하려 한다. 어제 저녁쯤에 패치가 되어 현재 해결이 된 상태지만 패치 갭을 생각해서 3달 정도 있다가 하는게 맞는 것 같다.
The details of CVE-2021-2127 will be released after 3 months, considering patch gaps of softwares. Even though the bug was fixed yesterday, I think it is right to disclose the bug after 3 months, considering the gaps.
QEMU의 113 포트 (SLiRP module)에서 힙 오버플로우 취약점이 존재해 해당 취약점을 통해 VM Escape을 얻은 케이스다. PoC가 주어져있는데, 아래와 같다.
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <netdb.h>
#include <arpa/inet.h>
#include <sys/socket.h>
int main() {
int s, ret;
struct sockaddr_in ip_addr;
char buf[0x500];
s = socket(AF_INET, SOCK_STREAM, 0);
ip_addr.sin_family = AF_INET;
ip_addr.sin_addr.s_addr = inet_addr("10.0.2.2"); // host IP
ip_addr.sin_port = htons(113); // vulnerable port
ret = connect(s, (struct sockaddr *)&ip_addr, sizeof(struct sockaddr_in));
memset(buf, 'A', 0x500);
while (1) {
write(s, buf, 0x500);
}
return 0;
}
113에 TCP로 계속해서 데이터를 넣는 모습을 확인할 수 있다. 데이터가 계속해서 써지면 결국 힙 오버플로우가 발생한다.
환경세팅
-enable-kvm 옵션을 사용하기 위해서는 우분투를 멀티부팅 형식으로 설치할 수밖에 없었다. Nested로 하는 방법도 존재했지만 시스템에 어떤 영향을 줄지 예상이 가지 않아 우분투를 설치하기로 마음먹었다.
우분투를 설치하는데 많은 트러블슈팅 과정을 거쳤다. 그램과 노트북, rufus / unetbootin / UUI를 번갈아 가며 설치를 시도했지만 결국에는 노트북에 기존에 가지고 있었던 Ubuntu 18.04.1 버전을 설치하였다. 노트북 BIOS 옵션에 들어가 꼭꼭 숨겨져있던 UEFI 옵션을 끄고서야 USB 부팅이 되었고, 그램에 설치를 시도할 때에는 UEFI 부팅을 끄는 옵션이 있었지만 Legacy Boot 옵션을 킬 수가 없어 (회색으로 처리되어 킬 수 없었다) Ubuntu 설치에 실패하였다.
9시간 정도 소모하여 간신히 우분투를 설치한 뒤에 기본적인 프로그램들을 설치하고 Qemu를 설치하였다. Qemu의 경우 버그가 발생한 Qemu의 정확한 버전을 알수가 없어 v3.1.0 버전을 사용하였다. 해당 버전의 코드를 확인하여 패치가 아직 이루어지지 않았음을 확인하였다. 해당 버전을 설치하는 과정은 다음과 같다.
git clone https://github.com/qemu/qemu
cd qemu
git reset --hard 32a1a94
mkdir build
cd build
../configure
make
cp x86_64-softmmu/qemu-system-x86_64 ../..
위 컴파일 과정을 위해서는 dependency들이 많이 필요한데 해당 리스트는 링크에서 구하였다.
Qemu를 설치했으면 이제 VM을 설치해야 한다. 18.04 우분투 이미지를 받아서 해당 이미지로부터 이미지를 생성해야 했다. 이미지를 생성하는 방법은 링크에서 배울 수 있었지만, 환경이 달라 약간의 조정이 필요했다. 최종적으로 사용한 명령어들은 아래와 같다.
위 명령어들을 실행하면 설치 과정을 실행할 수 있다. 실행해도 화면이 나오지 않는데, VNC server running on 127.0.0.1:5900 메세지를 보고 remmina 프로그램을 통해 VNC 서버에 접속하여 화면을 확인할 수 있었다. 설치 과정은 일반적인 우분투 설치 과정과 동일하다.
해당 설치 과정을 거쳤으면 이미지로부터 스냅샷을 생성해야 한다. 스냅샷은 기존 이미지와 다른 점들만 저장하는 용도로, 용량이 많이 줄어 용량을 아낄 수 있다. 해당 명령어는 아래와 같다.
해당영역에 보낸 데이터가 그대로 이어져서 붙어 나오는 것을 쉽게 확인할 수 있다. 멀티스레드 힙이기 때문에 map 상에는 단순하게 mapped 영역에 있는 것으로 보인다. 청크 사이즈는 0x2245 로 크기가 한정되어 있음을 확인할 수 있다.
이제 데이터를 더 밀어넣고 오버플로우가 발생하는지 확인해보자. 청크 크기+1 만큼 데이터를 밀어넣어 8바이트만큼 오버플로우가 발생하도록 하였다. (다음 청크의 사이즈가 덮이도록 설정하였다)
#!/usr/bin/python
from pwn import *
p = remote("10.0.2.2", 113)
p.send("A"*(0x400-6))
for i in xrange(7):
p.send("A"*0x400)
p.send("G"*0x239)
p.interactive()
해당 write-up을 보게 되면 malloc primitive를 IP Fragmentation을 통해 얻는 것을 확인할 수 있다. 아래 코드를 살펴보자.
// slirp/ip_input.c:184
/*
* If datagram marked as having more fragments
* or if this is not the first fragment,
* attempt reassembly; if it succeeds, proceed.
*/
if (ip->ip_tos & 1 || ip->ip_off) {
ip = ip_reass(slirp, ip, fp);
if (ip == NULL)
return;
m = dtom(slirp, ip);
} else
if (fp)
ip_freef(slirp, fp);
ip_reass 에서 리턴값을 NULL로 받게 되면 바로 return 해버리기 때문에 m_buf가 그대로 남아있는 것을 확인할 수 있다. ip_reass에서 리턴값이 NULL이 되는 경우는 다음과 같다.
fp == NULL
insert로 이동
큐 확인 후 해당 fragment 패킷을 삽입하는 것이 불가능하다. -> NULL 반환
하지만 해당 루틴까지 오기 위해 거쳐야 할 체크들이 존재한다. (아래 체크들이 만족하면 문제가 되며 바로 m_free 루틴으로 향한다)
m->m_len < sizeof (struct ip)
ip->ip_v != IPVERSION
hlen<sizeof(struct ip ) || hlen>m->m_len
cksum(m,hlen)
ip->ip_len < hlen
m->m_len < ip->ip_len
ip->ip_ttl == 0
마지막으로 ip->ip_off &~ IP_DF, ip->ip_tos & 1 || ip->ip_off 조건들도 만족해야 원하는 루틴을 트리거할 수 있다. 아래 코드를 작성하고 돌렸을 경우 malloc이 연속적으로 수행되면서 청크가 쌓인다.
// slirp/mbuf.c:129
/*
* Copy data from one mbuf to the end of
* the other.. if result is too big for one mbuf, allocate
* an M_EXT data segment
*/
void
m_cat(struct mbuf *m, struct mbuf *n)
{
/*
* If there's no room, realloc
*/
if (M_FREEROOM(m) < n->m_len)
m_inc(m, m->m_len + n->m_len);
memcpy(m->m_data+m->m_len, n->m_data, n->m_len);
m->m_len += n->m_len;
m_free(n);
}
ip_reass 의 루틴을 이용하여 m_cat을 호출할 수 있으며, m_cat 에서는 memcpy로 데이터를 복사하여 넣어준다. 이를 이용하여 arbitrary write를 얻을 수 있다. m_cat을 실행하는 것은 단순히 같은 ip id 에 대해 MF를 끈 상태로 패킷을 보내면 된다. 그러면 조작한 m_data와 m_len에 따라서 데이터가 복사되어 들어가게 된다.
Memory Leak
ICMP echo reply에 대한 rfc792 문서를 보게 되면 아래 내용을 확인할 수 있다.
The data received in the echo message must be returned in the echo reply message.
즉, 보낸 데이터를 그대로 다시 돌려준다는 것이다. 따라서 이를 이용하여 memory leak을 낼 것이다.
Arbitrary write에서 했던 것과 비슷하게 한다. 다만, 이번에는 m_data를 전체 다 덮는 것이 아니라 일부만 (하위 3바이트) 덮어서 메모리를 얻을 것이다. 익스플로잇 진행 흐름은 아래와 같다.
m_buf를 partial overwrite해서 힙의 다른 위치를 가리키게 한다.
MF=1로 ICMP request를 보낸다.
sbuf에서 heap overflow를 일으켜서 m_data의 하위 3바이트를 덮는다.
MF=0으로 ICMP request를 보낸다. (2와 같은 아이디로)
이를 통해 Host에 ICMP request를 보내면 echo reply로 게스트에 메모리 값들을 다시 보내주게 된다. 해당 데이터를 다시 받아 libc base 주소와 heap 주소를 얻으면 된다.
PC Control
PC Control의 경우 QEMUTimer를 이용하면 된다. 해당 코드는 아래와 같다.
// util/qemu-timer.c:68
struct QEMUTimerList {
QEMUClock *clock;
QemuMutex active_timers_lock;
QEMUTimer *active_timers;
QLIST_ENTRY(QEMUTimerList) list;
QEMUTimerListNotifyCB *notify_cb;
void *notify_opaque;
/* lightweight method to mark the end of timerlist's running */
QemuEvent timers_done_ev;
};
// include/qemu/timer.h:83
struct QEMUTimer {
int64_t expire_time; /* in nanoseconds */
QEMUTimerList *timer_list;
QEMUTimerCB *cb;
void *opaque;
QEMUTimer *next;
int attributes;
int scale;
};
QEMU timer에 관한 코드들은 위와 같다. main_loop_tlg 에 저장되어 있는 Timer 리스트를 가지고 와서 해당 리스트에 있는 timer의 cb 함수를 호출하게 된다. 따라서 fake timer list를 만든 뒤에 main_loop_tlg 를 덮어서 가짜로 만든 리스트를 참조하게 하면 된다. 그러면 cb에 넣은 함수 포인터를 참조하여 함수를 실행하게 되고, 이를 이용하여 PC Control을 얻을 수 있다.
힙의 적당한 위치에 arbitrary write primitive를 이용하여 fake timer list를 작성하고 다시 arbitrary write를 통해 main_loop_tlg를 덮어 fake timer list를 가리키게 하면 된다. cb에 system 함수를 넣으면 system을 실행해준다. cb 에 system을 넣고 opaque 에 명령어를 입력하면 (ex - "/bin/sh") system에 opaque에 들어가 있는 인자를 넣고 실행시킨다. 이를 통해 system에 원하는 명령어를 넣어 실행시킬 수 있다.
SLiRP에서 발생하는 힙 오버플로우 취약점을 성공적으로 익스플로잇할 수 있었다. 처음에 scapy를 이용하여 익스플로잇을 재구성하다가 실패하였고 그 원인을 6일간 삽질한 끝에 MTU를 조정하지 않았기 때문임을 알 수 있었다. 결국에는 주어진 익스플로잇 코드를 오프셋과 구조를 다시 변경하여 세팅한 환경에서 작동할 수 있도록 재구성하였고, 그 결과 성공적으로 익스플로잇을 할 수 있었다.
시간 관계상 scapy로 익스플로잇 코드를 재구성하는 것은 하지 못하지만 그래도 QEMU의 네트워크에서 발생하는 취약점을 어떻게 익스플로잇할 수 있는지 배울 수 있었다. 네트워크 프로토콜을 잘 조작하면 malloc primitive 등 원하는 기능을 수행할 수 있도록 바꿀 수 있다는 것을 확인할 수 있었고, 배우기만 했지만 직접 해보지 않았던 리얼월드에서 익스플로잇을 성공적으로 수행하기 위한 heap spray 기법 등을 이번 기회를 통해 직접 해볼 수 있었다.
마지막으로 security mitigation들이 모두 걸려있어 익스플로잇이 힘든 바이너리에서 QEMUTimer를 이용하여 익스플로잇을 할 수 있다는 것을 이번 익스플로잇 분석을 통해 배울 수 있었다.
이 문서에서는 QEMU USB에 대한 삽질 내용들을 다룬다. USB에 대한 퍼징 시도는 많지만 이를 VM 환경에서 수행한 사례가 많이 없기 때문에 USB 퍼저를 작성하려는 시도를 하려 한다. 또한, 그 시도에서 얻은 정보들을 이곳에 간략하게나마 정리하려 한다.
본문
VM 환경에서의 퍼징
VM 환경에서 퍼징하는데 많은 어려움이 있는데 이를 정리하면 아래와 같다.
High Overhead : 현실적으로 VM을 매 테스트케이스마다 껐다가 킬 수 없다. 따라서 VM을 켜놓은 상태에서 지속적인 (Persistent) 방법으로 퍼징을 수행해야 한다.
지속적인 방법으로 퍼징을 하려 한다면 퍼징 루프를 잘 설계해서 상태를 매 루프마다 원래대로 복구시켜줄 필요가 있다. 이는 테스트를 진행하는 사람이 져야 하는 위험이다. (Risk)
지속적인 방법에서 피드백을 지속적으로 제공해줄 수 있는 프록시 시스템이 필요하다.
테스트 하고 싶은 함수를 따로 고립시켜서 테스트 하는 방법도 있을 수 있겠지만 이는 생각보다 어렵다. 타겟의 전체적인 구조를 파악한 뒤에 시도해볼 만한 방법이다.
QEMU 모드 등을 사용 불가능하다. (Nested virtualization 환경에서 테스트를 제대로 할 수 있을까)
Instrumentation을 하는데 어려움이 많다. 컴파일 오류 등 여러 문제가 발생한다.
Interaction (Kernel)
기본적으로 실행 옵션에 USB를 주면 /sys/devices 아래 pciXXX 라는 이름으로 폴더가 생성된다. USB와 인터랙션을 하려면 해당하는 pci 디바이스에 찾아가서 resourceN에 r/w를 수행하면 된다. 일반적인 경우에는 open :arrow_right: mmap :arrow_right: memory r/w를 수행하는 방식으로 USB를 사용한다. 추가로 DMA 버퍼를 두는 경우가 있는데, 이 경우에는 mmap으로 추가로 페이지를 할당받은 뒤 mlock을 이용하여 swap out이 되지 않도록 막는다. (DMA 버퍼로 사용한다)
우리가 원하는 디바이스는 USB 디바이스이므로 00:01.2 디바이스를 참조하면 된다. 위 경우에는 해당 디바이스가 /sys/devices/pci0000:00/0000:00:01.2에 위치하게 된다.
만약에 디바이스가 PCI가 아닌 캐릭터 디바이스 레벨로 접근을 하고 싶다면 /dev/bus/usb 폴더 안을 찾아보면 된다. 디바이스가 제대로 인식되는지 확인하려면 lsusb 명령어를 실행하여 리스트에 디바이스가 있는지 확인하면 된다. 캐릭터 디바이스도 PCI 디바이스와 마찬가지로 mmap과 메모리 연산을 통해 접근할 수 있다.
Analysis
Basic Structure
기본적으로 USB 에뮬레이터가 3가지 파트로 구성되어 있다.
Raw data parsing
State machine to track USB state
Handler (read, can_read, event)
또한, 이들은 프런트엔드와 백엔드로 구성되어 있다. 아래 내용을 보자.
https://www.qemu.org/docs/master/qemu-doc.html#Character-device-options A character device may be used in multiplexing mode by multiple front-ends. Specify mux=on to enable this mode. A multiplexer is a "1:N" device, and here the "1" end is your specified chardev backend, and the "N" end is the various parts of QEMU that can talk to a chardev. If you create a chardev with id=myid and mux=on, QEMU will create a multiplexer with your specified ID, and you can then configure multiple front ends to use that chardev ID for their input/output. Up to four different front ends can be connected to a single multiplexed chardev. (Without multiplexing enabled, a chardev can only be used by a single front end.) For instance you could use this to allow a single stdio chardev to be used by two serial ports and the QEMU monitor
프런트엔드와 백엔드 사이엔 MUX가 있어서 하나의 백엔드에 여러 프런트엔드를 연결할 수 있는 것으로 보인다. 즉, char device 하나로 두개의 디바이스를 제어할 수 있게 되는 것이다. 아래 링크의 단축키로 MUX를 제어할 수 있다.
hw/usb/core.c에는 USB core 부분이 구현되어 있다. USB 탈부착이나 raw USB 패킷 파싱을 이 부분에서 진행한다.
dev-***, desc
각각의 디바이스에 해당하는 패킷을 처리하거나 특수한 에뮬레이션이 필요한 것들을 제공한다. 어떻게 보면 기본적인 드라이버 부분을 제공하는 것으로, 예를 들어 시리얼 통신의 경우 -serial 옵션을 주었을 경우 가상 디바이스를 생성해서 이를 에뮬레이션한다. 가상 디바이스에 들어오는 패킷들을 처리하거나 그에 맞는 동작들을 수행한다.
hcd-***
HCD (Host Controller Driver)에 해당하는 동작들을 수행한다. HCI 동작들을 수행하는 역할을 한다. USB 2.0, 3.0 등의 디바이스가 추가되었을 때 그에 알맞는 기능들을 수행한다.
Comment
전체적으로 state machine과 패킷 파싱 부분으로 깔끔하게 분리될 수 있고 각 부분이 워낙 명확하게 구현되어 있기 때문에 개발자가 실수할 부분이 많지가 않다. 그나마 취약점이 나올만한 부분이 HCD 쪽인데, 해당 부분을 테스트하기 힘들 뿐인 데다가 복잡도가 좀 있기 때문이다. 하지만 이 부분도 취약점이 나온 전적이 많지 않고 나왔더라도 임팩트가 낮은 취약점이어서 여기서 추가로 유의미한 취약점이 나올 수 있을지 의문이다.
결론
지금까지 USB에 대해 분석하였고, QEMU에서 어떤 부분들을, 또 어떻게 에뮬레이션해서 서비스를 제공하는지 알아보았다. USB는 기본적으로 좋은 벡터지만 QEMU의 경우 워낙 명확하게 패킷들을 처리하고 또 보안쪽으로 많이 신경썼기 때문에 (디바이스에 대한 퍼저가 따로 존재할 정도) 취약점이 나오기 힘들 것으로 사료된다.
