최근 거의 한달 반 정도 동안 크롬을 보면서 겪은게 fetch chromium이 모종의 이유로 실패하는 것이었습니다. 같은 경우를 겪는 사람이 있을지도 모른다는 생각에 해결법을 올립니다.

 

fetch --nohooks chromium을 실행했을 때 bad_scm 뭐시기 폴더가 생기고 파이썬 오류로 "No file or directory" 와 비슷한 맥락의 오류가 뜰 때가 있습니다. 해당 오류는 git의 문제이므로 git config를 수정하면 됩니다.

 

git config --global https.postbuffer 4194304000

git config --global http.postbuffer 4194304000

 

이 두 문구를 실행하고나서 fetch --nohooks --no-history chromium을 실행합니다. 그러면 어느 정도 받아지다가 오류가 날 텐데, 그 상태에서 gclient sync를 실행하면 전부 받아지게 됩니다.

 

많은 사람들에게 도움이 됐으면 합니다.

'보안 > Bug Hunting' 카테고리의 다른 글

fetch --nohooks chromium 고치기  (1) 2021.06.19
My Fuzzers  (2) 2021.02.21
QEMU USB Analysis and Fuzzing  (0) 2021.01.19
CCID Protocol  (0) 2021.01.19
VirtualBox SVGA  (0) 2021.01.19
  1. l33d0hyun 2021.09.14 11:24 신고

    크롬까지... ㄷㄷ

Fuzzer list that I and my team VirtualBoBs wrote during BoB project.

The levels of these fuzzers are not that high, but I think it is worth opening them.

Haven't found any bugs from these, but it is worth trying to run them, hunting bugs.

 

1. Network Protocol Fuzzer working in VMs (possibly targeting SLiRP)

https://github.com/VirtualBoBs/QEMUSLNetFuzz

 

2. VirtualBox VMSVGA 3d Fuzzer (possibly for VMware as well)

https://github.com/VirtualBoBs/VBox-SVGA3D-fuzzing 

'보안 > Bug Hunting' 카테고리의 다른 글

fetch --nohooks chromium 고치기  (1) 2021.06.19
My Fuzzers  (2) 2021.02.21
QEMU USB Analysis and Fuzzing  (0) 2021.01.19
CCID Protocol  (0) 2021.01.19
VirtualBox SVGA  (0) 2021.01.19
  1. candymate 2021.03.04 15:25 신고

    Closed VMSVGA 3d fuzzer because of personal reasons.

  2. candymate 2021.04.24 18:00 신고

    VMSVGA Fuzzer now open to public (following by the disclosure of CVE-2021-2266)

주의

지극히 개인적인 의견만 들어가 있습니다.

소개

이 문서에서는 QEMU USB에 대한 삽질 내용들을 다룬다. USB에 대한 퍼징 시도는 많지만 이를 VM 환경에서 수행한 사례가 많이 없기 때문에 USB 퍼저를 작성하려는 시도를 하려 한다. 또한, 그 시도에서 얻은 정보들을 이곳에 간략하게나마 정리하려 한다.

본문

VM 환경에서의 퍼징

VM 환경에서 퍼징하는데 많은 어려움이 있는데 이를 정리하면 아래와 같다.

  1. High Overhead : 현실적으로 VM을 매 테스트케이스마다 껐다가 킬 수 없다. 따라서 VM을 켜놓은 상태에서 지속적인 (Persistent) 방법으로 퍼징을 수행해야 한다.
    1. 지속적인 방법으로 퍼징을 하려 한다면 퍼징 루프를 잘 설계해서 상태를 매 루프마다 원래대로 복구시켜줄 필요가 있다. 이는 테스트를 진행하는 사람이 져야 하는 위험이다. (Risk)
    2. 지속적인 방법에서 피드백을 지속적으로 제공해줄 수 있는 프록시 시스템이 필요하다.
    3. 테스트 하고 싶은 함수를 따로 고립시켜서 테스트 하는 방법도 있을 수 있겠지만 이는 생각보다 어렵다. 타겟의 전체적인 구조를 파악한 뒤에 시도해볼 만한 방법이다.
  2. QEMU 모드 등을 사용 불가능하다. (Nested virtualization 환경에서 테스트를 제대로 할 수 있을까)
  3. 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 버퍼로 사용한다)

참고 : https://www.kernel.org/doc/Documentation/filesystems/sysfs-pci.txt

어떤 PCI 디바이스가 원하는 USB 디바이스인지 확인하기 위해 lspci 명령어를 사용할 수 있다. 해당 명령어를 실행하면 아래처럼 결과가 나온다.

vm@vm:/sys/devices/pci0000:00/0000:00:01.0$ lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 VGA compatible controller: Device 1234:1111 (rev 02)
00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03)

우리가 원하는 디바이스는 USB 디바이스이므로 00:01.2 디바이스를 참조하면 된다. 위 경우에는 해당 디바이스가 /sys/devices/pci0000:00/0000:00:01.2에 위치하게 된다.

만약에 디바이스가 PCI가 아닌 캐릭터 디바이스 레벨로 접근을 하고 싶다면 /dev/bus/usb 폴더 안을 찾아보면 된다. 디바이스가 제대로 인식되는지 확인하려면 lsusb 명령어를 실행하여 리스트에 디바이스가 있는지 확인하면 된다. 캐릭터 디바이스도 PCI 디바이스와 마찬가지로 mmap과 메모리 연산을 통해 접근할 수 있다.

Analysis

Basic Structure

기본적으로 USB 에뮬레이터가 3가지 파트로 구성되어 있다.

  1. Raw data parsing
  2. State machine to track USB state
  3. 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를 제어할 수 있다.

https://www.qemu.org/docs/master/qemu-doc.html#mux_005fkeys

core

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의 경우 워낙 명확하게 패킷들을 처리하고 또 보안쪽으로 많이 신경썼기 때문에 (디바이스에 대한 퍼저가 따로 존재할 정도) 취약점이 나오기 힘들 것으로 사료된다.

'보안 > Bug Hunting' 카테고리의 다른 글

fetch --nohooks chromium 고치기  (1) 2021.06.19
My Fuzzers  (2) 2021.02.21
QEMU USB Analysis and Fuzzing  (0) 2021.01.19
CCID Protocol  (0) 2021.01.19
VirtualBox SVGA  (0) 2021.01.19

주의

여기에 남긴 내용은 지극히 개인적인 의견들입니다. 틀릴 가능성이 80% 이상입니다.

소개

CCID (Chip Card Interface Device) 프로토콜은 스마트카드 (USB) 에서 사용하는 프로토콜이다. 이는 스마트카드가 하나의 보안 토큰으로 사용될 수 있게 한다. (주로 Two-factor authentication에 사용된다) QEMU의 경우 스마트카드 사용 옵션을 붙여서 컴파일을 해주면 게스트에서 해당 디바이스를 사용할 수 있고, 이를 공략하기 위해 해당 프로토콜을 분석한다.

프로토콜에 대한 공식적인 문서는 링크에 포함되어 있다. 하지만, 프로토콜에 대한 설명이 너무 장황한 데에다가 하드웨어 부분들도 모두 설명되어 있기 때문에 공식 문서를 통해 프로토콜에 대한 정보를 얻는 것은 많이 어렵다. 따라서 본인은 QEMU에 구현된 에뮬레이터 코드를 보고 프로토콜에 대한 정보를 얻으려 한다.

본문

디바이스 특성

디바이스는 캐릭터 디바이스 형태로 구현되어 있으며 QEMU 게스트 안에서 /dev/bus/usb/001/002 형태로 나타난다. 디바이스 이름은 GemPC433-Swap으로 이를 검색해보면 스마트카드 디바이스임을 확인할 수 있다.

vm@vm:/dev/bus/usb/001$ lsusb
Bus 001 Device 002: ID 08e6:4433 Gemalto (was Gemplus) GemPC433-Swap
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

위에서 보이듯이 캐릭터 디바이스 형태이기 때문에 해당 디바이스를 접근하는 방법으로는 두가지가 있다. (1) 커널 모듈을 작성해서 캐릭터 디바이스와 통신하면 된다. 하지만 커널 모듈을 작성하고 올려보고 하는 과정이 많이 복잡하기 때문에 이보다는 다른 방법을 사용하는 것이 편하다. (2) 해당 디바이스 /dev/bus/usb/001/002를 통해 파일 읽기 및 쓰기를 하면서 통신할 수 있다. 자세한 내용은 아래 인용에 나와있다.

https://stackoverflow.com/questions/9276345/checking-simple-char-device-read-write-functions-in-linux

Documentation

자세한 내용을 설명하기 전에 참고할만한 자료들을 일부 소개해놓고 시작하려 한다.

  1. libcacard (Smartcard emulation library)
    1. Git page : https://gitlab.freedesktop.org/spice/libcacard
    2. Documentation : https://github.com/cedric-vincent/qemu/blob/master/docs/libcacard.txt
  2. CCID documentation in QEMU : https://github.com/qemu/qemu/blob/master/docs/ccid.txt
  3. APDU : https://en.wikipedia.org/wiki/Smart_card_application_protocol_data_unit#:~:text=In%20the%20context%20of%20smart,security%20and%20commands%20for%20interchange.
  4. VSCard Protocol (QEMU) : https://wiki.qemu.org/Features/Smartcard
  5. CCID 발표자료 : https://pt.slideshare.net/ssuserf27290/what-is-smart-card-on-tam?smtNoRedir=1

디바이스 종류

QEMU에서 구현하는 디바이스는 두가지가 있다.

  1. passthru protocol을 사용하는 스마트카드 디바이스 (-device ccid-card-passthru)
  2. certificate 파일이나 실제 하드웨어를 기반으로 하는 NSS 벡엔드가 존재하는 에뮬레이터 (-device ccid-card-emulated)

위 두가지 경우 이외에도 실제 스마트카드 디바이스와 버스 역할만 해주는 경우도 있다. (-device usb-ccid)

APDU

APDU는 스마트카드와 단말기가 통신하는 메세지 단위다. 크게 Command APDU와 Response APDU로 나누어지며 Command APDU는 단말기가 카드에게 전달하는 메세지인 반면 Response APDU는 카드가 단말기에 전달하는 메세지다. 형식은 아래와 같다.

Mandatory Field는 CLA, INS, P1, P2, SW1, SW2이다. 나머지 바이트는 선택이다.

마지막으로, 통신 모델은 아래와 같다.

Emulated

Emulated의 경우 certificate 파일이나 실제 하드웨어를 기반으로 하는 NSS 백엔드가 존재한다. 실행 옵션에 -device ccid-card-emulated를 넣고 실행하면 게스트에서 접근할 수 있는 스마트카드 디바이스가 생성되고, 해당 디바이스를 통해 유저는 certificate 정보를 획득할 수 있다. NSS 백엔드의 상태에 따라 state machine에 transition이 발생하고 (ex - 카드 삽입, 제거, 읽기, ...) state에 따라 해당하는 액션이 취해진다.

전체적인 코드 구조는 USB와 동일하다. 간단한 state machine과 handler로 구현되어 있다. 복잡도가 그렇게 높지 않아 개발자가 실수할 포인트가 많지 않고 따라서 취약점이 나오기 힘들 것으로 생각된다. 또한, 게스트 입장에서 해당 디바이스를 공략할 수 있는 것은 백엔드와 상호작용하는 부분인데, 게스트 입장에서 가능한 것은 APDU로 요청을 보내서 APDU Response를 받아오는 것밖에 없다. 즉, APDU 패킷들이 하나의 벡터가 되는 것인데, 해당 패킷들을 처리하는 것이 복잡하지 않고 개발자가 실수할 수 있는 포인트가 적어 취약점이 나오기 힘들다.

Passthru

Passthrough의 경우 VSCard 프로토콜을 추가로 구현한다. 해당 프로토콜은 APDU 기반으로 동작하며, 시나리오는 아래와 같다.

https://github.com/qemu/qemu/blob/master/docs/ccid.txt

Passthrough도 마찬가지로 정해진 상태 머신을 따라가며 handler로 구성되어 차례대로 메세지를 처리하니 위와 마찬가지로 개발자가 실수할 수 있는 포인트가 적다. 따라서 마찬가지로 취약점이 나오기 힘들 것으로 사료된다.

결론

  1. CCID의 경우 공략할 부분이 passthru 밖에 없음. 왜냐면 certificate의 경우 호스트에서 파일을 제공하고 실행 옵션에 넣어야 하기 때문.
  2. 이유를 알지 못하지만 char device로 스마트 카드 디바이스가 접근이 불가능함. (Read는 되는데 Write가 안됨) 또한 Spice를 사용하면 스마트 카드에 대해 삽입/제거 시뮬레이션을 할 수 있다고 하는데 (shift-f8, shift-f9) 이를 사용하려면 별도의 컴파일 옵션과 실행 옵션이 필요해서 이게 게스트에서 사용할 수 있는 기능인가 의아함.
  3. CCID의 경우 사람들이 많이 사용하지 않는 기능으로 보임. Two-factor authentication으로 사용하는 이 기능은 개발자가 간략히 개발하고 넘어가는 것으로 생각됨. 하지만 생각보다 보안 관련 기능이다 보니 모듈 자체에 보안을 많이 신경썼다는 느낌이 강함.
  4. 프로토콜 정보의 경우 APDU에 대한 내용은 위키, CCID 자체에 대한 내용은 123쪽짜리 공식 문서가 있음.
  5. passthru에 관한 코드는 굉장히 짧음. State machine / handler 구조가 끝.
  6. libcacard라는 외부 라이브러리를 사용하는데 해당 라이브러리에는 libfuzzer로 구현된 자체 퍼저가 있음. 파싱 부분과 encoding / decoding 부분에 대한 퍼징을 수행함.
  7. 해당 부분이 터진 경우는 딱 한번 있는데, memory corruption 류나 logic bug 류가 아니라 단순하게 메모리가 계속 쌓여서 DoS가 발생하는 경우.

'보안 > Bug Hunting' 카테고리의 다른 글

fetch --nohooks chromium 고치기  (1) 2021.06.19
My Fuzzers  (2) 2021.02.21
QEMU USB Analysis and Fuzzing  (0) 2021.01.19
CCID Protocol  (0) 2021.01.19
VirtualBox SVGA  (0) 2021.01.19

소개

VirtualBox의 디스플레이 세팅을 보게 되면 Graphicss Controller와 Acceleration 세팅이 있다. 해당 컨트롤러에서 VMSVGA를 선택하면 SVGA를 사용하게 된다. Linux를 OS로 선택하면 3D acceleration 옵션까지 켤 수 있다.

이 문서에서는 SVGA의 내부 구조와 작동 방식에 대해 설명한다.

Contents

Graphics Device Architecture

SVGA는 해당 옵션이 켜져 있을 때 게스트에서 해당 디바이스의 커널 드라이버를 통해 접근할 수 있다. 크게 두 방법으로 접근 가능한데, (1) MMIO를 통한 FIFO 메모리 접근, (2) Port I/O를 통한 SVGA Register 접근이 가능하다. 해당 두 상태를 설정해놓으면 VM 구현 코드에서 데이터를 가져가 상태에 맞는 기능을 수행하게 된다. 위 그림의 경우 VMware 기준으로 설명이 되어 있지만 VirtualBox도 동일한 방식으로 작동한다.

SVGA Structure and Port I/O

SVGA의 경우 게스트 입장에서는 PCI 디바이스를 통해 접근할 수 있다. 위 도식에서 BAR 0, 1, 2는 각각 I/O 포트 번호, 글로벌 프레임 버퍼의 물리 주소, FIFO의 물리 주소를 나타낸다. IRQ의 경우 Interrupt Request의 약자로 인터럽트가 들어오는 것을 처리하는데 사용된다. I/O를 처리하는 것을 아래 코드로 살펴보자.

// VBox/Graphics/DevVGA.cpp:6661
pThis->hIoPortVmSvga    = NIL_IOMIOPORTHANDLE;
pThis->hMmio2VmSvgaFifo = NIL_PGMMMIO2HANDLE;
if (pThis->fVMSVGAEnabled)
{
    /* Register the io command ports. */
    rc = PDMDevHlpPCIIORegionCreateIo(pDevIns, pThis->pciRegions.iIO, 0x10, vmsvgaIOWrite, vmsvgaIORead, NULL /*pvUser*/,
                                      "VMSVGA", NULL /*paExtDescs*/, &pThis->hIoPortVmSvga);
    AssertRCReturn(rc, rc);

    rc = PDMDevHlpPCIIORegionCreateMmio2Ex(pDevIns, pThis->pciRegions.iFIFO, pThis->svga.cbFIFO,
                                           PCI_ADDRESS_SPACE_MEM, 0 /*fFlags*/, vmsvgaR3PciIORegionFifoMapUnmap,
                                           "VMSVGA-FIFO", (void **)&pThisCC->svga.pau32FIFO, &pThis->hMmio2VmSvgaFifo);
    AssertRCReturn(rc, PDMDevHlpVMSetError(pDevIns, rc, RT_SRC_POS,
                                           N_("Failed to create VMSVGA FIFO (%u bytes)"), pThis->svga.cbFIFO));

    pPciDev->pfnRegionLoadChangeHookR3 = vgaR3PciRegionLoadChangeHook;
}

위 코드에서 I/O 핸들링을 어떻게 하는지, FIFO MMIO를 어떻게 처리할지에 대한 설정을 하고 있음을 확인할 수 있다. VRAM의 경우에는 VMSVGA 세팅에 상관없이 VGA에서 처리한다.

// VBox/Devices/Graphics/DevVGA.cpp:6680
/*
 * Allocate VRAM and create a PCI region for it.
 */
rc = PDMDevHlpPCIIORegionCreateMmio2Ex(pDevIns, pThis->pciRegions.iVRAM, pThis->vram_size,
                                       PCI_ADDRESS_SPACE_MEM_PREFETCH, 0 /*fFlags*/, vgaR3PciIORegionVRamMapUnmap,
                                       "VRam", (void **)&pThisCC->pbVRam, &pThis->hMmio2VRam);
AssertLogRelRCReturn(rc, PDMDevHlpVMSetError(pDevIns, rc, RT_SRC_POS,
                                                 N_("Failed to allocate %u bytes of VRAM"), pThis->vram_size));

SVGA Handling

SVGA I/O나 MMIO로 접근하게 되면 vmsvgaIORead, vmsvgaIOWrite 콜백 함수들에서 해당 데이터들을 처리하게 된다. 들어오는 포트에 따라 이를 처리하는 루틴이 달라진다.

// VBox/Devices/Graphics/DevVGA-SVGA.cpp:2037
/**
 * @callback_method_impl{FNIOMIOPORTNEWIN}
 */
DECLCALLBACK(VBOXSTRICTRC) vmsvgaIORead(PPDMDEVINS pDevIns, void *pvUser, RTIOPORT offPort, uint32_t *pu32, unsigned cb)
{
    PVGASTATE   pThis = PDMDEVINS_2_DATA(pDevIns, PVGASTATE);
    RT_NOREF_PV(pvUser);

    /* Only dword accesses. */
    if (cb == 4)
    {
        switch (offPort)
        {
            case SVGA_INDEX_PORT:
                *pu32 = pThis->svga.u32IndexReg;
                break;

            case SVGA_VALUE_PORT:
                return vmsvgaReadPort(pDevIns, pThis, pu32);

            case SVGA_BIOS_PORT:
                Log(("Ignoring BIOS port read\n"));
                *pu32 = 0;
                break;

            case SVGA_IRQSTATUS_PORT:
                LogFlow(("vmsvgaIORead: SVGA_IRQSTATUS_PORT %x\n", pThis->svga.u32IrqStatus));
                *pu32 = pThis->svga.u32IrqStatus;
                break;

            default:
                ASSERT_GUEST_MSG_FAILED(("vmsvgaIORead: Unknown register %u was read from.\n", offPort));
                *pu32 = UINT32_MAX;
                break;
        }
    }
    else
    {
        Log(("Ignoring non-dword I/O port read at %x cb=%d\n", offPort, cb));
        *pu32 = UINT32_MAX;
    }
    return VINF_SUCCESS;
}

vmsvgaReadPortvmsvgaWritePort에서는 SVGA Register 값들을 세팅하게 된다. 예를들어, SVGA_REG_ID로 값을 읽으려 시도하면 SVGA id가 리턴된다.

반면에 FIFO 메모리와 VRAM의 경우 직접 해당 메모리 영역에 값을 쓰게 된다. (각각 pThisCC->svga.pau32FIFO, pThisCC->pbVRam) FIFO의 경우 이후 FIFO loop에서 커맨드를 하나씩 잘라서 처리하게 된다.

SVGA PCI Device

게스트 입장에서 SVGA 디바이스에 접근할 때에는 PCI 디바이스를 통해 접근할 수 있다. 게스트 입장에서 볼 수 있는 PCI 디바이스는 다음과 같다.

vm@vm:~$ lspci
(...)
00:02.0 VGA compatible controller: VMware SVGA II Adapter
(...)

코드상으로 해당 PCI 디바이스를 찾아 연결하기 위해서 vendor와 device id를 맞춰주어야 한다. 해당 id들은 svga_reg.h에 정의되어 있다.

// VBox/Devices/Graphics/vmsvga/svga_reg.h:41
/*
 * PCI device IDs.
 */
#define PCI_VENDOR_ID_VMWARE            0x15AD
#define PCI_DEVICE_ID_VMWARE_SVGA2      0x0405

코드상으로 연결하는 방법은 다양한 방법이 있지만 libpciaccess를 이용하여 연결하는 예시 코드는 아래와 같다.

// https://github.com/renorobert/virtualbox-vmsvga-bugs/blob/master/CVE-2017-10210/svga.c
int conf_svga_device(void)
{
    struct pci_device *dev;
    struct pci_device_iterator *iter;
    struct pci_id_match match;
    uint16_t command;

    if (getuid() != 0 || geteuid() != 0) 
        errx(EXIT_FAILURE, "[!] Run program as root");

    iopl(3);

    if (pci_system_init())
        return -1;

    match.vendor_id = PCI_VENDOR_ID_VMWARE;
    match.device_id = PCI_DEVICE_ID_VMWARE_SVGA2;
    match.subvendor_id = PCI_MATCH_ANY;
    match.subdevice_id = PCI_MATCH_ANY;
    match.device_class = 0;
    match.device_class_mask = 0;

    iter = pci_id_match_iterator_create(&match);
    dev = pci_device_next(iter);

    if (dev == NULL) {
        pci_cleanup(iter);
        return -1;
    }

    pci_device_probe(dev);

    gSVGA.ioBase = dev->regions[0].base_addr;
    gSVGA.fbMem = (void *)dev->regions[1].base_addr;
    gSVGA.fifoMem = (void *)dev->regions[2].base_addr;

    command = pci_device_cfg_read_u16(dev, 0, 4);
    pci_device_cfg_write_u16(dev, command | 7, 4);

    SVGA_WriteReg(SVGA_REG_ID, SVGA_ID_2);
    SVGA_WriteReg(SVGA_REG_ENABLE, true);

    gSVGA.vramSize = SVGA_ReadReg(SVGA_REG_VRAM_SIZE);
    gSVGA.fbSize = SVGA_ReadReg(SVGA_REG_FB_SIZE);
    gSVGA.fifoSize = SVGA_ReadReg(SVGA_REG_MEM_SIZE);

    pci_device_map_range(dev, (pciaddr_t)gSVGA.fbMem, (pciaddr_t)gSVGA.fbSize,
            PCI_DEV_MAP_FLAG_WRITABLE, (void *)&gSVGA.fbMem);
    pci_device_map_range(dev, (pciaddr_t)gSVGA.fifoMem, (pciaddr_t)gSVGA.fifoSize,
            PCI_DEV_MAP_FLAG_WRITABLE, (void *)&gSVGA.fifoMem);

    pci_cleanup(iter);

    return 0;
}

FIFO Command Handling

FIFO buffer로 MMIO를 수행하게 되면 FIFO loop (vmsvgaR3FifoLoop)에서 커맨드로 잘라서 해당하는 커맨드를 수행하게 된다. 기본적으로 커맨드 구조는 아래를 따른다.

  1. 커맨드 넘버

    // VBox/Devices/Graphics/vmsvga/svga_reg.h:1010
    typedef enum {
    SVGA_CMD_INVALID_CMD           = 0,
    SVGA_CMD_UPDATE                = 1,
    SVGA_CMD_RECT_COPY             = 3,
    SVGA_CMD_DEFINE_CURSOR         = 19,
    SVGA_CMD_DEFINE_ALPHA_CURSOR   = 22,
    SVGA_CMD_UPDATE_VERBOSE        = 25,
    SVGA_CMD_FRONT_ROP_FILL        = 29,
    SVGA_CMD_FENCE                 = 30,
    SVGA_CMD_ESCAPE                = 33,
    SVGA_CMD_DEFINE_SCREEN         = 34,
    SVGA_CMD_DESTROY_SCREEN        = 35,
    SVGA_CMD_DEFINE_GMRFB          = 36,
    SVGA_CMD_BLIT_GMRFB_TO_SCREEN  = 37,
    SVGA_CMD_BLIT_SCREEN_TO_GMRFB  = 38,
    SVGA_CMD_ANNOTATION_FILL       = 39,
    SVGA_CMD_ANNOTATION_COPY       = 40,
    SVGA_CMD_DEFINE_GMR2           = 41,
    SVGA_CMD_REMAP_GMR2            = 42,
    SVGA_CMD_MAX
    } SVGAFifoCmdId;
    
    // VBox/Devices/Graphics/vmsvga/svga3d\_reg.h:1031  
    #define SVGA\_3D\_CMD\_LEGACY\_BASE 1000  
    #define SVGA\_3D\_CMD\_BASE 1040
    
    #define SVGA\_3D\_CMD\_SURFACE\_DEFINE SVGA\_3D\_CMD\_BASE + 0 // Deprecated  
    #define SVGA\_3D\_CMD\_SURFACE\_DESTROY SVGA\_3D\_CMD\_BASE + 1  
    #define SVGA\_3D\_CMD\_SURFACE\_COPY SVGA\_3D\_CMD\_BASE + 2  
    #define SVGA\_3D\_CMD\_SURFACE\_STRETCHBLT SVGA\_3D\_CMD\_BASE + 3  
    #define SVGA\_3D\_CMD\_SURFACE\_DMA SVGA\_3D\_CMD\_BASE + 4  
    #define SVGA\_3D\_CMD\_CONTEXT\_DEFINE SVGA\_3D\_CMD\_BASE + 5  
    #define SVGA\_3D\_CMD\_CONTEXT\_DESTROY SVGA\_3D\_CMD\_BASE + 6  
    #define SVGA\_3D\_CMD\_SETTRANSFORM SVGA\_3D\_CMD\_BASE + 7  
    #define SVGA\_3D\_CMD\_SETZRANGE SVGA\_3D\_CMD\_BASE + 8  
    #define SVGA\_3D\_CMD\_SETRENDERSTATE SVGA\_3D\_CMD\_BASE + 9  
    #define SVGA\_3D\_CMD\_SETRENDERTARGET SVGA\_3D\_CMD\_BASE + 10  
    #define SVGA\_3D\_CMD\_SETTEXTURESTATE SVGA\_3D\_CMD\_BASE + 11  
    #define SVGA\_3D\_CMD\_SETMATERIAL SVGA\_3D\_CMD\_BASE + 12  
    #define SVGA\_3D\_CMD\_SETLIGHTDATA SVGA\_3D\_CMD\_BASE + 13  
    #define SVGA\_3D\_CMD\_SETLIGHTENABLED SVGA\_3D\_CMD\_BASE + 14  
    #define SVGA\_3D\_CMD\_SETVIEWPORT SVGA\_3D\_CMD\_BASE + 15  
    #define SVGA\_3D\_CMD\_SETCLIPPLANE SVGA\_3D\_CMD\_BASE + 16  
    #define SVGA\_3D\_CMD\_CLEAR SVGA\_3D\_CMD\_BASE + 17  
    #define SVGA\_3D\_CMD\_PRESENT SVGA\_3D\_CMD\_BASE + 18 // Deprecated  
    #define SVGA\_3D\_CMD\_SHADER\_DEFINE SVGA\_3D\_CMD\_BASE + 19  
    #define SVGA\_3D\_CMD\_SHADER\_DESTROY SVGA\_3D\_CMD\_BASE + 20  
    #define SVGA\_3D\_CMD\_SET\_SHADER SVGA\_3D\_CMD\_BASE + 21  
    #define SVGA\_3D\_CMD\_SET\_SHADER\_CONST SVGA\_3D\_CMD\_BASE + 22  
    #define SVGA\_3D\_CMD\_DRAW\_PRIMITIVES SVGA\_3D\_CMD\_BASE + 23  
    #define SVGA\_3D\_CMD\_SETSCISSORRECT SVGA\_3D\_CMD\_BASE + 24  
    #define SVGA\_3D\_CMD\_BEGIN\_QUERY SVGA\_3D\_CMD\_BASE + 25  
    #define SVGA\_3D\_CMD\_END\_QUERY SVGA\_3D\_CMD\_BASE + 26  
    #define SVGA\_3D\_CMD\_WAIT\_FOR\_QUERY SVGA\_3D\_CMD\_BASE + 27  
    #define SVGA\_3D\_CMD\_PRESENT\_READBACK SVGA\_3D\_CMD\_BASE + 28 // Deprecated  
    #define SVGA\_3D\_CMD\_BLIT\_SURFACE\_TO\_SCREEN SVGA\_3D\_CMD\_BASE + 29  
    #define SVGA\_3D\_CMD\_SURFACE\_DEFINE\_V2 SVGA\_3D\_CMD\_BASE + 30  
    #define SVGA\_3D\_CMD\_GENERATE\_MIPMAPS SVGA\_3D\_CMD\_BASE + 31  
    #define SVGA\_3D\_CMD\_ACTIVATE\_SURFACE SVGA\_3D\_CMD\_BASE + 40  
    #define SVGA\_3D\_CMD\_DEACTIVATE\_SURFACE SVGA\_3D\_CMD\_BASE + 41  
    #define SVGA\_3D\_CMD\_MAX SVGA\_3D\_CMD\_BASE + 42
  2. 커맨드 헤더 (id (지워짐), header size)

    // VBox/Devices/Graphics/vmsvga/svga3d_reg.h:1126
    /*
    * The data size header following cmdNum for every 3d command
    */
    typedef
    struct {
    /* uint32_t               id; duplicate*/
    uint32_t               size;
    } SVGA3dCmdHeader;
  3. 커맨드 body

    // example of command body
    
    STRUCTURE <svga3d\_reg.struct\_c\_\_SA\_SVGA3dCmdSetRenderState object at 0x7fbbcbe0a7b8>  
    FIELD cid (type=<class 'ctypes.c\_uint'>, bitlen=32)  
    VALUE = 103 (type=<class 'int'>)  
    STRUCTURE <svga3d\_reg.struct\_c\_\_SA\_SVGA3dRenderState object at 0x7fbbcbe0a7b8>  
    FIELD state (type=<class 'ctypes.c\_int'>, bitlen=32)  
    VALUE = 700967841 (type=<class 'int'>)  
    FIELD \_1 (type=<class 'svga3d\_reg.union\_c\_\_SA\_SVGA3dRenderState\_0'>, bitlen=32)  
    STRUCTURE <svga3d\_reg.union\_c\_\_SA\_SVGA3dRenderState\_0 object at 0x7fbbcbe0a8c8>  
    FIELD uintValue (type=<class 'ctypes.c\_uint'>, bitlen=32)  
    VALUE = 1482925787 (type=<class 'int'>)  
    FIELD floatValue (type=<class 'ctypes.c\_float'>, bitlen=32)  
    VALUE = 1001223113146368.0 (type=<class 'float'>)

4바이트씩 잘라서 MMIO로 데이터를 넘기면 FIFO buffer에 차례대로 들어간다. 이후 FIFO loop에서 커맨드 번호를 읽고, 헤더 사이즈를 읽은 뒤 헤더사이즈에 맞게 FIFO buffer에서 dequeue를 해서 커맨드를 읽는다. 읽은 커맨드는 커맨드 종류에 맞춰 기능을 수행하게 된다.

SVGA state에 따라 external command를 수행하는 경우도 있다. External command에는 reset, power off, save / load state 등이 있는데, SVGA 커맨드에 상관 없이 외부 요인에 의해 실행된다. (PCI command로 실행시킬 수도 있다. ex - /sys/bus/pci/devices/<device no.>/power)

// VBox/Devices/Graphics/DevVGA-SVGA.cpp:3529 (inside vmsvgaR3FifoLoop)
/*
 * Special mode where we only execute an external command and the go back
 * to being suspended.  Currently, all ext cmds ends up here, with the reset
 * one also being eligble for runtime execution further down as well.
 */
if (pThis->svga.fFifoExtCommandWakeup)
{
    vmsvgaR3FifoHandleExtCmd(pDevIns, pThis, pThisCC);
    while (pThread->enmState == PDMTHREADSTATE_RUNNING)
        if (pThis->svga.u8FIFOExtCommand == VMSVGA_FIFO_EXTCMD_NONE)
            PDMDevHlpSUPSemEventWaitNoResume(pDevIns, pThis->svga.hFIFORequestSem, RT_MS_1MIN);
        else
            vmsvgaR3FifoHandleExtCmd(pDevIns, pThis, pThisCC);
    return VINF_SUCCESS;
}

References

  1. VMware SVGA Device Developer Kit: https://sourceforge.net/projects/vmware-svga/ (Alternative: https://github.com/prepare/vmware-svga)
  2. Straight outta VMware: Modern exploitation of the SVGA device for guest-to-host escape exploits (Blackhat Europe 2018): https://i.blackhat.com/eu-18/Thu-Dec-6/eu-18-Sialveras-Straight-Outta-VMware-Modern-Exploitation-Of-The-SVGA-Device-For-Guest-To-Host-Escapes.pdf
  3. https://github.com/renorobert/virtualbox-vmsvga-bugs

'보안 > Bug Hunting' 카테고리의 다른 글

fetch --nohooks chromium 고치기  (1) 2021.06.19
My Fuzzers  (2) 2021.02.21
QEMU USB Analysis and Fuzzing  (0) 2021.01.19
CCID Protocol  (0) 2021.01.19
VirtualBox SVGA  (0) 2021.01.19

+ Recent posts