Downloaded 15 times
![Architecture Overview
Virtualization Software Process
(VSP)
Customized BIOS System
(CBS)
Instrumented Target
Virtual Device X
(e.g. USB)
Memory / IO space
Host OS
Device Control
Client
(DCC)
Virtual
Serial
Port
Memory and IO space
Operation Proxy Server
(MIOPS )
afl-fuzz
Device control data
(DCD)
Virtual Device1
(e.g. NIC,
e1000)
Virtual Device2
(e.g. SCSI)
Virtual Device3
(e.g. Printer)
Virtual Device4
(e.g. Audio
Card)
AFL Target Processes (ATP)
Memory/IO Access
request (MIOA request)
Commands entry
[1] instrument target device
[2] afl-fuzz loop
[3] DCC read in DCD
[4]
MIOPS
execute
request](https://image.slidesharecdn.com/whenvirtualizationencountersafl-blackhateu2016-1-161104163919/75/When-virtualization-encounters-afl-blackhat-eu2016-1-4-10-2048.jpg)
![Workflow Overview
Virtualization Software Process
(VSP)
Customized BIOS System
(CBS)
Instrumented Target
Virtual Device X
(e.g. USB)
Memory / IO space
Host OS
Device Control
Client
(DCC)
Virtual
Serial
Port
Memory and IO space
Operation Proxy Server
(MIOPS )
afl-fuzz
Device control data
(DCD)
Virtual Device1
(e.g. NIC,
e1000)
Virtual Device2
(e.g. SCSI)
Virtual Device3
(e.g. Printer)
Virtual Device4
(e.g. Audio
Card)
AFL Target Processes (ATP)
Memory/IO Access
request (MIOA request)
Commands entry
[1] instrument target device
[2] afl-fuzz loop
[3] DCC read in DCD
[4]
MIOPS
execute
request
[5] afl-fuzz caculate code coverage and mutate](https://image.slidesharecdn.com/whenvirtualizationencountersafl-blackhateu2016-1-161104163919/75/When-virtualization-encounters-afl-blackhat-eu2016-1-4-19-2048.jpg)
![Workflow Overview- Step 1
Virtualization Software Process
(VSP)
Customized BIOS System
(CBS)
Instrumented Target
Virtual Device X
(e.g. USB)
Memory / IO space
Host OS
Device Control
Client
(DCC)
Virtual
Serial
Port
Memory and IO space
Operation Proxy Server
(MIOPS )
afl-fuzz
Device control data
(DCD)
Virtual Device1
(e.g. NIC,
e1000)
Virtual Device2
(e.g. SCSI)
Virtual Device3
(e.g. Printer)
Virtual Device4
(e.g. Audio
Card)
AFL Target Processes (ATP)
Memory/IO Access
request (MIOA request)
Commands entry
[1] instrument target device
[2] afl-fuzz loop
[3] DCC read in DCD
[4]
MIOPS
execute
request
[5] afl-fuzz caculate code coverage and mutate](https://image.slidesharecdn.com/whenvirtualizationencountersafl-blackhateu2016-1-161104163919/75/When-virtualization-encounters-afl-blackhat-eu2016-1-4-21-2048.jpg)
![Workflow Overview- Step 2
Virtualization Software Process
(VSP)
Customized BIOS System
(CBS)
Instrumented Target
Virtual Device X
(e.g. USB)
Memory / IO space
Host OS
Device Control
Client
(DCC)
Virtual
Serial
Port
Memory and IO space
Operation Proxy Server
(MIOPS )
afl-fuzz
Device control data
(DCD)
Virtual Device1
(e.g. NIC,
e1000)
Virtual Device2
(e.g. SCSI)
Virtual Device3
(e.g. Printer)
Virtual Device4
(e.g. Audio
Card)
AFL Target Processes (ATP)
Memory/IO Access
request (MIOA request)
Commands entry
[1] instrument target device
[2] afl-fuzz loop
[3] DCC read in DCD
[4]
MIOPS
execute
request
[5] afl-fuzz caculate code coverage and mutate](https://image.slidesharecdn.com/whenvirtualizationencountersafl-blackhateu2016-1-161104163919/75/When-virtualization-encounters-afl-blackhat-eu2016-1-4-23-2048.jpg)
![• Step3:Encode MIOA Requests to DCD and read into DCC
Work Flow-
Encode DCD and read in – Step 3
typedef struct _command_entry
{
u32 _slotid;
u32 _command_id;
void* _inctx;
u8 _input_buf[32];
}command_entry_t;](https://image.slidesharecdn.com/whenvirtualizationencountersafl-blackhateu2016-1-161104163919/75/When-virtualization-encounters-afl-blackhat-eu2016-1-4-24-2048.jpg)
![Workflow Overview – Step3
Virtualization Software Process
(VSP)
Customized BIOS System
(CBS)
Instrumented Target
Virtual Device X
(e.g. USB)
Memory / IO space
Host OS
Device Control
Client
(DCC)
Virtual
Serial
Port
Memory and IO space
Operation Proxy Server
(MIOPS )
afl-fuzz
Device control data
(DCD)
Virtual Device1
(e.g. NIC,
e1000)
Virtual Device2
(e.g. SCSI)
Virtual Device3
(e.g. Printer)
Virtual Device4
(e.g. Audio
Card)
AFL Target Processes (ATP)
Memory/IO Access
request (MIOA request)
Commands entry
[1] instrument target device
[2] afl-fuzz loop
[3] DCC read in DCD
[4]
MIOPS
execute
request
[5] afl-fuzz caculate code coverage and mutate](https://image.slidesharecdn.com/whenvirtualizationencountersafl-blackhateu2016-1-161104163919/75/When-virtualization-encounters-afl-blackhat-eu2016-1-4-25-2048.jpg)
![Workflow Overview – Step 4
Virtualization Software Process
(VSP)
Customized BIOS System
(CBS)
Instrumented Target
Virtual Device X
(e.g. USB)
Memory / IO space
Host OS
Device Control
Client
(DCC)
Virtual
Serial
Port
Memory and IO space
Operation Proxy Server
(MIOPS )
afl-fuzz
Device control data
(DCD)
Virtual Device1
(e.g. NIC,
e1000)
Virtual Device2
(e.g. SCSI)
Virtual Device3
(e.g. Printer)
Virtual Device4
(e.g. Audio
Card)
AFL Target Processes (ATP)
Memory/IO Access
request (MIOA request)
Commands entry
[1] instrument target device
[2] afl-fuzz loop
[3] DCC read in DCD
[4]
MIOPS
execute
request
[5] afl-fuzz caculate code coverage and mutate](https://image.slidesharecdn.com/whenvirtualizationencountersafl-blackhateu2016-1-161104163919/75/When-virtualization-encounters-afl-blackhat-eu2016-1-4-28-2048.jpg)
![Work Flow-
In view of AFL
Virtualization Software Process
(VSP)
AFL Instrumented Target
Virtual Device X
Device
Control
Client
(DCC)
afl-fuzz
Device control data
(DCD)
AFL Target Processes (ATP)
[2] Remove afl instrument existence check
in afl-fuzz and launch afl-fuzz DCC
[3] DCC read in DCD
[8] afl-fuzz caculates code coverage (of VSP) and
mutate DCD and record crash (of VSP)
[1]AFL instrument device parts in
VSP (e.g.QEMU)
[4] DCC
communicate to VSP
with Qtest and wait
for VSP
[5] VSP crashes
[6] waitpid() returns
[7] DCC Checks returned
crash status(WIFSIGNALED)
and crash itself](https://image.slidesharecdn.com/whenvirtualizationencountersafl-blackhateu2016-1-161104163919/75/When-virtualization-encounters-afl-blackhat-eu2016-1-4-29-2048.jpg)
![Tips: Compile the source code in part using afl-gcc, for example:
Makefile:
%.o: %.c
$(call quiet-command,
if [ $@ = "hw/usb/hcd-xhci.o" -o $@ = "hw/usb/dev-storage.o" ] ;
AFL Tips-
Part Instrumentation - Compile Source1/2](https://image.slidesharecdn.com/whenvirtualizationencountersafl-blackhateu2016-1-161104163919/75/When-virtualization-encounters-afl-blackhat-eu2016-1-4-30-2048.jpg)
![1. afl-gcc fdc.c
2. Designing input case file(i.e. DCD) format
struct fdc_command
{
unsigned char cid;
unsigned int args_count;
unsigned int args[0];
};
Case Study 1/3](https://image.slidesharecdn.com/whenvirtualizationencountersafl-blackhateu2016-1-161104163919/75/When-virtualization-encounters-afl-blackhat-eu2016-1-4-37-2048.jpg)
More Related Content
![[若渴計畫] Black Hat 2017之過去閱讀相關整理](https://cdn.slidesharecdn.com/ss_thumbnails/blackhat2017-170416150012-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to When virtualization encounters afl blackhat eu2016--1.4
![Automating ISP Networks Using Ansible and IPAM as a Source of Truth [SoT]](https://cdn.slidesharecdn.com/ss_thumbnails/automatingispnetworksusingansibleandipamasasourceoftruthsot-v25-1-251124105117-d7d4ca24-thumbnail.jpg?width=640&height=640&fit=bounds)
When virtualization encounters afl blackhat eu2016--1.4
- 1. When virtualization encountersAFL Jack Tang, @jacktang310 Moony Li, @Flyic
- 2. What We WillCover • Who We Are • Approach • Implementation • Case Study • CVE-2015-3456, Venom • Demo
- 4. Jack Tang - @jacktang310 -10+ years security - Browser - Document - Mac/Windows Kernel - Virtualization Vulnerability
- 5. Moony Li - @Flyic -7 years security - Sandcastle - Deep Discovery - Exploit Detection - Mac/Windows Kernel - Android Vulnerability
- 6. Approaches Comparison Approach NotesPros Cons Fuzz in guest OS 1.Capture 2.Replay & Fuzz 1.Simple 2.Ignorance of I/O protocol 1.No code coverage 2.Incomplete by design Conformance fuzzing test 1.Symbol Execution 1.Fuzz deeper 1.No code coverage 2.Acdemical Code Review 1.Fexible 1.Cost effort 2.No scalable
- 7. Target: Virtual Devices Hypervisor GuestOS Virtual Devices Hardware Devices Guest OS Virtual Devices Kernel Driver Kernel Driver
- 8. • Portable • CustomizedBIOS as common format Virtual Disk • Serial port • Performance • sizeof(BIOS)<sizeof(OS). • Direct • Bypass device driver layer • Code coverage feedback & control • AFL integration Our Approach
- 9. Implementation • Architecture • Modules •Work Flow • AFL Tips
- 10. Architecture Overview Virtualization SoftwareProcess (VSP) Customized BIOS System (CBS) Instrumented Target Virtual Device X (e.g. USB) Memory / IO space Host OS Device Control Client (DCC) Virtual Serial Port Memory and IO space Operation Proxy Server (MIOPS ) afl-fuzz Device control data (DCD) Virtual Device1 (e.g. NIC, e1000) Virtual Device2 (e.g. SCSI) Virtual Device3 (e.g. Printer) Virtual Device4 (e.g. Audio Card) AFL Target Processes (ATP) Memory/IO Access request (MIOA request) Commands entry [1] instrument target device [2] afl-fuzz loop [3] DCC read in DCD [4] MIOPS execute request
- 11.
- 12. • Customized BIOSSystem(Seabios) • Decision principle: • Portability • Contains MIOPS(Memory and IO space Operation Proxy Server) • VSP (Virtual Software Process) is its runtime instance • Virtual serial port • Communication bridge Modules-CBS 1/3
- 13. Modules- How ToCustomize CBS 2/3 POST phase (Power On Self Test) Boot phase (Boot Operating System) BIOS runtime service phase (BIOS service for runtime OS) • Traditional BIOS vs Customized BIOS
- 14. Modules- How ToCustomize CBS 3/3 POST phase (Power On Self Test) • Detect physical memory • Platform hardware setup (for example: PCI bus, clock…) • Necessary device hardware setup (for example: serial port device for communication) • Recognize the devices • Start to run MIOPS (Memory and IO space Operation Proxy Server) handle loop.
- 15. • Memory andIO space Operation Proxy Server • MIOA Request- (Memory I/O Access) request • Tips: • Remove interruption in CBS • MIOPS polls virtual device result of request with timeout Modules-MIOPS 1/2
- 16. • Job: • ReceiveMIOA • Execution it Modules-MIOPS 2/2 MIOA example: “inb <address>” “inw <address>” “inl <address>” “outb <address> <value>” “outw <address> <value>” “outl <address> <value>” “write <address> <value> <length>” “read <address> <length>”
- 17. • Device ControlClient • DCD – Device Control Data • Formatted suitable for AFL • Steps in Job: • 1. Launch VSP to load CBS • 2. Ping MIOPS in CBS Modules-DCC 1/2 mkfifo jack_pipe mkfifo jack_pipe1 qemu-system-x86_64 -bios out/bios.bin -serial pipe:jack_pipe -serial pipe:jack_pipe1
- 18. • Steps inJob: • 3. Initialize target virtual device • e.g. USB XHCI device initialization • 4. Parse DCD to MIOA Requests Modules-DCC 2/2
- 19. Workflow Overview Virtualization SoftwareProcess (VSP) Customized BIOS System (CBS) Instrumented Target Virtual Device X (e.g. USB) Memory / IO space Host OS Device Control Client (DCC) Virtual Serial Port Memory and IO space Operation Proxy Server (MIOPS ) afl-fuzz Device control data (DCD) Virtual Device1 (e.g. NIC, e1000) Virtual Device2 (e.g. SCSI) Virtual Device3 (e.g. Printer) Virtual Device4 (e.g. Audio Card) AFL Target Processes (ATP) Memory/IO Access request (MIOA request) Commands entry [1] instrument target device [2] afl-fuzz loop [3] DCC read in DCD [4] MIOPS execute request [5] afl-fuzz caculate code coverage and mutate
- 20. • Step1:Instrument thetarget devices • source code is available • Afl-gcc compile source code in part • source code NOT available • Instrument executable file statically + restricted instrumentation range Work Flow- Setup instrumentation-Step1/4
- 21. Workflow Overview- Step1 Virtualization Software Process (VSP) Customized BIOS System (CBS) Instrumented Target Virtual Device X (e.g. USB) Memory / IO space Host OS Device Control Client (DCC) Virtual Serial Port Memory and IO space Operation Proxy Server (MIOPS ) afl-fuzz Device control data (DCD) Virtual Device1 (e.g. NIC, e1000) Virtual Device2 (e.g. SCSI) Virtual Device3 (e.g. Printer) Virtual Device4 (e.g. Audio Card) AFL Target Processes (ATP) Memory/IO Access request (MIOA request) Commands entry [1] instrument target device [2] afl-fuzz loop [3] DCC read in DCD [4] MIOPS execute request [5] afl-fuzz caculate code coverage and mutate
- 22. • Step2:Launch Afl-fuzzloop • afl-fuzz -t 90 -m 2048 -i ${test_root}/IN/ -o ${test_root}/OUT/ ${DCC} @@ • Afl-fuzll will automatically mutate DCD and calculate code coverage in the loop Work Flow- Setup Trace & Feedback – Step 2/4
- 23. Workflow Overview- Step2 Virtualization Software Process (VSP) Customized BIOS System (CBS) Instrumented Target Virtual Device X (e.g. USB) Memory / IO space Host OS Device Control Client (DCC) Virtual Serial Port Memory and IO space Operation Proxy Server (MIOPS ) afl-fuzz Device control data (DCD) Virtual Device1 (e.g. NIC, e1000) Virtual Device2 (e.g. SCSI) Virtual Device3 (e.g. Printer) Virtual Device4 (e.g. Audio Card) AFL Target Processes (ATP) Memory/IO Access request (MIOA request) Commands entry [1] instrument target device [2] afl-fuzz loop [3] DCC read in DCD [4] MIOPS execute request [5] afl-fuzz caculate code coverage and mutate
- 24. • Step3:Encode MIOARequests to DCD and read into DCC Work Flow- Encode DCD and read in – Step 3 typedef struct _command_entry { u32 _slotid; u32 _command_id; void* _inctx; u8 _input_buf[32]; }command_entry_t;
- 25. Workflow Overview –Step3 Virtualization Software Process (VSP) Customized BIOS System (CBS) Instrumented Target Virtual Device X (e.g. USB) Memory / IO space Host OS Device Control Client (DCC) Virtual Serial Port Memory and IO space Operation Proxy Server (MIOPS ) afl-fuzz Device control data (DCD) Virtual Device1 (e.g. NIC, e1000) Virtual Device2 (e.g. SCSI) Virtual Device3 (e.g. Printer) Virtual Device4 (e.g. Audio Card) AFL Target Processes (ATP) Memory/IO Access request (MIOA request) Commands entry [1] instrument target device [2] afl-fuzz loop [3] DCC read in DCD [4] MIOPS execute request [5] afl-fuzz caculate code coverage and mutate
- 26. Work Flow- Control DevicesCommunicate –Step 4/4 VSP CBS Instrumented Target Virtual Device X Memory / IO space DCC MIOPS DCD Initialize Finalize Communicate Initialize Communicate Finalize In/out/DMA
- 27. • Step4: CommunicationLoop • CBS starts up • Start & discover devices • Start MIOPS in it • MIOPS starts up • Initiate target devices • E.g. doorbell/command/event address of USB XHCI device • Communicate between MIOPS and DCC until crash • DCC read in DCD • MIOPS execute data Work Flow- Control Devices Communicate - Step 4/4
- 28. Workflow Overview –Step 4 Virtualization Software Process (VSP) Customized BIOS System (CBS) Instrumented Target Virtual Device X (e.g. USB) Memory / IO space Host OS Device Control Client (DCC) Virtual Serial Port Memory and IO space Operation Proxy Server (MIOPS ) afl-fuzz Device control data (DCD) Virtual Device1 (e.g. NIC, e1000) Virtual Device2 (e.g. SCSI) Virtual Device3 (e.g. Printer) Virtual Device4 (e.g. Audio Card) AFL Target Processes (ATP) Memory/IO Access request (MIOA request) Commands entry [1] instrument target device [2] afl-fuzz loop [3] DCC read in DCD [4] MIOPS execute request [5] afl-fuzz caculate code coverage and mutate
- 29. Work Flow- In viewof AFL Virtualization Software Process (VSP) AFL Instrumented Target Virtual Device X Device Control Client (DCC) afl-fuzz Device control data (DCD) AFL Target Processes (ATP) [2] Remove afl instrument existence check in afl-fuzz and launch afl-fuzz DCC [3] DCC read in DCD [8] afl-fuzz caculates code coverage (of VSP) and mutate DCD and record crash (of VSP) [1]AFL instrument device parts in VSP (e.g.QEMU) [4] DCC communicate to VSP with Qtest and wait for VSP [5] VSP crashes [6] waitpid() returns [7] DCC Checks returned crash status(WIFSIGNALED) and crash itself
- 30. Tips: Compile thesource code in part using afl-gcc, for example: Makefile: %.o: %.c $(call quiet-command, if [ $@ = "hw/usb/hcd-xhci.o" -o $@ = "hw/usb/dev-storage.o" ] ; AFL Tips- Part Instrumentation - Compile Source1/2
- 31. Tips: Instrument theexecutable file for close-source software AFL Tips- Part Instrumentation – Instrument PE 2/2 Data Segment Code Segment PE Header Segment Table Target Code Range Entry Point Trampoline SegmentInitialization static const u8* trampoline_f ".align 4n" "leal -16(%%esp), %%espn" "movl %%edi, 0(%%esp)n" "movl %%edx, 4(%%esp)n" "movl %%ecx, 8(%%esp)n" "movl %%eax, 12(%%esp)n" "movl $0x%08x, %%ecxn" "call __afl_maybe_logn" "movl 12(%%esp), %%eaxn" "movl 8(%%esp), %%ecxn" "movl 4(%%esp), %%edxn" "movl 0(%%esp), %%edin" "leal 16(%%esp), %%espn"
- 32. AFL Tips- Multiple Processes1/3 Target Process (e.g. VSP) AFL Instrument Launcher (e.g. DCC) afl-fuzz Input Data (e.g.DCD)
- 33. • Trace infois shared across processes in nature • static inline void afl_maybe_log(abi_ulong cur_loc) AFL Tips- Multiple Processes 2/3
- 34.
- 35. • Adjust parameterfor afl-fuzz to avoid start failure • -t, set more time for fuzz cycle • -m, set more memory for virtual machine • E.g. afl-fuzz -t 9 -m 2048 -i ${test_root}/IN/ -o ${test_root}/OUT/ ${DCC} @@ • … AFL Tips- Misc
- 36. What We WillCover • Case Study • Fuzz FDC and Reproduce Venom Vulnerability(CVE-2015-3456) • Demo
- 37. 1. afl-gcc fdc.c 2.Designing input case file(i.e. DCD) format struct fdc_command { unsigned char cid; unsigned int args_count; unsigned int args[0]; }; Case Study 1/3
- 38. 3. Prepare 30input case file • each case for one floppy disk controller command • For example: FD_CMD_READ, FD_CMD_WRITE, FD_CMD_SEEK… 4. Preparing DCC • Parsing input case file and translating to MIOA requests Case Study 2/3
- 39. 5. Using commandsto start testing afl-fuzz -t 99000 -m 2048 -i IN/ -o OUT/ <DCC command> @@ Case Study 3/3
- 40.
- 41.
- 42. • http://venom.crowdstrike.com/ • http://www.slideshare.net/CanSecWest/csw2016-tang-virtualizationdevice-emulator- testing-technology •http://lcamtuf.coredump.cx/AFL/ • https://www.youtube.com/watch?v=O9P7kXm5WSg • Filesystem Fuzzing with American Fuzzy Lop https://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%2 0fuzzing,%20Vault%202016_0.pdf • Triforce-run-afl-on-everything https://www.nccgroup.trust/us/about-us/newsroom-and- events/blog/2016/june/project-triforce-run-afl-on-everything/ • https://www.seabios.org/SeaBIOS • https://www.seabios.org/Execution_and_code_flow • http://wiki.qemu.org/Features/QTest • http://www.intel.com/content/www/us/en/io/universal-serial-bus/extensible-host- controler-interface-usb-xhci.html • http://wiki.osdev.org/Floppy_Disk_Controller Reference
- 43.
Editor's Notes
- #2 Welcome everyone I’m very happy to be presenting here today at the BLACKHAT conference. My name is Moony and I will be presenting today on the topic of virtualization fuzzing with AFL….
- #3 Today I will cover several key areas 1. First I’ll tell you a little about me and my partner I’ll then walk you through - how we designed our approach to fuzz virtual devices integrated with AFL - and how we implemented our design 3. Following this I will present to you a case study to show how we fuzz and reproduce a floppy vulnerability step by step 4. Finally I will give you a video demo.
- #5 My partners name is Jack Jack has worked in security for 10 years His focus has been on browser and document vulnerabilities as well as Mac – Windows and virtualization vulnerabilities. Jack can’t be with us today. He has broken his leg and cannot travel.
- #6 My name is Moony I’ve worked for 7 years in security. My role has been developing sandbox systems. Focusing on Mac - Windows and Android Kernel vulnerabilities.
- #7 Here I will compare several approaches about hunting virtualization vulnerabilities. The first approach is to fuzz IO communication from the guest Os. The basic procedure includes capturing the traffic first, replaying it, then fuzzing it. This is a very simple process and requires no knowledge of i/o protocol. The Con is that there is no code coverage and feedback. This means the fuzz is incomplete by design. Conformance fuzz testing is the second approach. The main principle is to introduce Symbolic Execution to IO communication leading to a deeper fuzz scope. Again there is no code coverage and this approach is mainly academic. Finally we look at Code review. This approach is more flexible for the researcher however, it takes more effort and is not scalable.
- #8 Actually there are many attacking interfaces in the virtual machine, however, we only focus on the area relating to virtual devices.
- #9 Our approach has several advantages – it is portable, it performs well, it is direct and has code coverage feedback and control. The main part of our solution is customized BIOS which is a common format. The performance is good because the size of the BIOS is usually much smaller than guest OS. Because we communicated directly with the virtual devices, fuzzing could bypass the interference from the device’s driver layer Because we have AFL integration we can get code coverage, feedback and can control fuzzing. 1. Portable Our solution has few requirements to target virtualization software. The only requirement is the target virtualization software can start customized BIOS in a guest with a serial port device. So our approach can support a number of virtualization software. 2. Good performance The fuzzing part of our solution do not depend on guest operation system which is usually time-consuming to bootstrap and run. Because the customized BIOS system does almost nothing but direct I/O with devices, the speed to launch the BIOS system is very fast. 3. Direct The solution directly communicates with virtual device without communicating with device drivers. In most case, device driver’s code is much complex and vulnerable than virtual device code. By communicating directly with virtual device, we can avoid interference from the device driver. Code coverage feedback & control This is why we introduce AFL. AFL’s function let our solution get the capabilities.
- #10 So I would now like to introduce our implementation in detail. We will look at the architecture of the solution first and show the solution modules. I will then introduce the solution’s work flow and provide some AFL tips for integration.
- #11 This is the architecture overview. The architecture can be divided into 4 parts – CBS | DCC | DCD and AFL The CBS is the customised BIOS system which is loaded through a virtualisation software process. The DCC will read in the DCD and communicate with the CBS. We have integrated AFL into the DCC and CBS There are five key stages in the workflow. First we will instrument target device with AFL in VSP. AFLfuzz will then launch DCC and VSP. The DCC will then read the DCD and communicate with the CBS. MIOPs in the CBS will execute the request until the CBS crashes. AFLfuzz will calculate the code coverage and mutate the DCD during the whole process
- #12 The is a glance at the fuzzing UI.
- #13 CBS is the main module in the entire solution. Actually it is a customised BIOS system which is named SEABIOS. The CBS contains MIOPS (Memory, IO Space, Operation Proxy Server) The VSP is the runtime instance of CBS We have also introduced the Virtual Serial Port which is the communication bridge between CBS and DCC
- #16 The MIOPS main job is to receive the MIOA request first from the DCC and then execute the request until the CBS crashes. The MIOA request looks like this … The parse function in MIOPS is like this ...
- #17 The MIOPS main job is to receive the MIOA request first from the DCC and then execute the request until the CBS crashes. The MIOA request looks like this … The parse function in MIOPS is like this ...
- #18 The DCC will read in the DCD formatted specifically for AFL. It’s main job is to launch the VSP to CBS, then ping MIOPS in CBS. IN several cases the DCC will initialize the target virtual device and will then parse DCD to MIOA.
- #20 This is the architecture overview. The architecture can be divided into 4 parts – CBS | DCC | DCD and AFL The CBS is the customised BIOS system which is loaded through a virtualisation software process. The DCC will read in the DCD and communicate with the CBS. We have integrated AFL into the DCC and CBS There are five key stages in the workflow. First we will instrument target device with AFL in VSP. AFLfuzz will then launch DCC and VSP. The DCC will then read the DCD and communicate with the CBS. MIOPs in the CBS will execute the request until the CBS crashes. AFLfuzz will calculate the code coverage and mutate the DCD during the whole process
- #21 To set up the AFL trace we should instrument the target devices first. If the virtual machine is open source, it will compare the source code with AFL-GCC If the source code is not open source, we should instrument the PE file with a restricted range. The command line for AFL fuzz is like this …
- #23 To set up the AFL trace we should instrument the target devices first. If the virtual machine is open source, it will compare the source code with AFL-GCC If the source code is not open source, we should instrument the PE file with a restricted range. The command line for AFL fuzz is like this …
- #25 Because we have integrated AFL to virtual device fuzz we should encode the MIOA request to DCD which is formatted especially for AFL. This is a sample of the DCD format about USB device
- #26 This is the architecture overview. The architecture can be divided into 4 parts – CBS | DCC | DCD and AFL The CBS is the customised BIOS system which is loaded through a virtualisation software process. The DCC will read in the DCD and communicate with the CBS. We have integrated AFL into the DCC and CBS There are five key stages in the workflow. First we will instrument target device with AFL in VSP. AFLfuzz will then launch DCC and VSP. The DCC will then read the DCD and communicate with the CBS. MIOPs in the CBS will execute the request until the CBS crashes. AFLfuzz will calculate the code coverage and mutate the DCD during the whole process
- #27 About the control device communication the DCC would communicate with CBS just like this…
- #28 In the first instance CBS will start up, discover the devices and begin the long job of MIOPS. After the MIOPS starts up it will initialize the target devices and receive requests from DCC. The DCC will read in DCD and communicate with the MIOPS until the CBS crashes. Step 1: AFL target processes start up VSP would load up CBS as its guest VM which is relatively light weight. CBS in guest VM would start and discover the attached device, then start MIOPS. Step 2: After MIOPS is ready, DCC would communicate with MIOPS to initialize the target devices. For example: target virtual device is USB XHCI device, the basic information include doorbell address, command ring address, event address . Step 3: After target device is ready, DCC will read in DCD as sequence of commands and analysis the command into MIOA request. Step 4: MIOPS would receive the MIOA request through virtual serial port, will execute corresponding request. For example, if MIOPS receives request “out 0xf000 0x8” in MIOA request, it will use out instruction to access port address 0xf000 with data 0x8.
- #29 This is the architecture overview. The architecture can be divided into 4 parts – CBS | DCC | DCD and AFL The CBS is the customised BIOS system which is loaded through a virtualisation software process. The DCC will read in the DCD and communicate with the CBS. We have integrated AFL into the DCC and CBS There are five key stages in the workflow. First we will instrument target device with AFL in VSP. AFLfuzz will then launch DCC and VSP. The DCC will then read the DCD and communicate with the CBS. MIOPs in the CBS will execute the request until the CBS crashes. AFLfuzz will calculate the code coverage and mutate the DCD during the whole process
- #30 Let me now introduce the workflow from an AFL view First the AFL will instrument the devices in VSP (e.g. QEMU) – the AFL Fuzz will launch the DCC. The DCC will read in the DCD and will communicate with the VSP in a large loop. If the VSP crashes waitpid will return. IN that case the DCC will be notified and it will crash itself. Finally the AFL Fuzz will be notified because of the DCC crash. It will calculate mutated DCD and record the crash (of the VSP)
- #31 Here are tips for AFL integration. The first is how we compare part of the source code using AFL, This is an example … %.o: %.c $(call quiet-command,\ if [ $@ = "hw/usb/hcd-xhci.o" -o $@ = "hw/usb/dev-storage.o" ] ;\ then \ echo afl-gcc... $< $@ ;\ afl-gcc $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) $($@-cflags) -c -o $@ $< ;\ else \ echo cc... $< $@ ; \ $(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) $($@-cflags) -c -o $@ $< ;\
- #33 Another tip is how to launch multiple processes using AFL . The scenario would look like this in our solution.
- #34 Actually AFL supports multiple process traces because he trace information is located in shared memory. You should remove the instrumentation check in Al Fuzz, because the launcher contains no AFL code. The launcher must crash itself if the target process crashes and the AFL Fuzz will be notified.
- #35 The pseudo code for AFL fuzz towards multiple processes will look like this fpid = fork(); if (fpid == 0) { //In child process launchVSP(argv); exit(0); } else { //In parent process (DCC) waitpid(fpid, &status, 0); if (WIFEXITED(status)) { //Child process normal exit, bypass } else if (WIFSIGNALED(status)) { //Child process crash signal, crash self crashMyself(); } }
- #36 There are also miscellaneous tips for example: To avoid start up failure, you should adjust the parameters for AFL Fuzz.
- #37 In this final part we will introduce a case study and show you a demo
- #38 The case is about floppy disc vulnerability. Hunt and reproduction using AFL. First we will compare the FDC source code. The FDC command will be encoded like this… Initially in the DCC module several pipes will be made and the DCC will launch the QEMU process. The process will launch bios.bin which contains CBS. Finally we start up AFL Fuzz like this … Step 1: Using AFL-gcc to compile fdc.c [moony add real command] Step 2: Designing input case file format One input case file contains several commands struct fdc_command { unsigned char cid; unsigned int args_count; unsigned int args[0]; }; The field cid is the floppy disk controller command ID. As I mentioned above , the structures will be translated to MIOA requests. Step 3. We prepare 30 input case file (one case input file for each floppy disk control command) Step 4: Preparing DCC Parsing input case file and translating to MIOA requests. Fork VSP , using following commands: mkfifo jack_pipe mkfifo jack_pipe1 qemu-system-x86_64 -bios out/bios.bin -serial pipe:jack_pipe -serial pipe:jack_pipe1 The bios.bin is CBS . Open pipe, and write MIOA requests to pipe and read response from pipe. Wait the VSP ‘s pid. Step 4: Using commands to start testing. afl-fuzz -t 99000 -m 2048 -i IN/ -o OUT/ <DCC command> In our testing environment (8G ram, 4 cores CPU), running the solution about 1.5 hours, we reproduce the Venom vulnerability on the QEMU 2.3.
- #39 The case is about floppy disc vulnerability. Hunt and reproduction using AFL. First we will compare the FDC source code. The FDC command will be encoded like this… Initially in the DCC module several pipes will be made and the DCC will launch the QEMU process. The process will launch bios.bin which contains CBS. Finally we start up AFL Fuzz like this … Step 1: Using AFL-gcc to compile fdc.c [moony add real command] Step 2: Designing input case file format One input case file contains several commands struct fdc_command { unsigned char cid; unsigned int args_count; unsigned int args[0]; }; The field cid is the floppy disk controller command ID. As I mentioned above , the structures will be translated to MIOA requests. Step 3. We prepare 30 input case file (one case input file for each floppy disk control command) Step 4: Preparing DCC Parsing input case file and translating to MIOA requests. Fork VSP , using following commands: mkfifo jack_pipe mkfifo jack_pipe1 qemu-system-x86_64 -bios out/bios.bin -serial pipe:jack_pipe -serial pipe:jack_pipe1 The bios.bin is CBS . Open pipe, and write MIOA requests to pipe and read response from pipe. Wait the VSP ‘s pid. Step 4: Using commands to start testing. afl-fuzz -t 99000 -m 2048 -i IN/ -o OUT/ <DCC command> In our testing environment (8G ram, 4 cores CPU), running the solution about 1.5 hours, we reproduce the Venom vulnerability on the QEMU 2.3.
- #40 The case is about floppy disc vulnerability. Hunt and reproduction using AFL. First we will compare the FDC source code. The FDC command will be encoded like this… Initially in the DCC module several pipes will be made and the DCC will launch the QEMU process. The process will launch bios.bin which contains CBS. Finally we start up AFL Fuzz like this … Step 1: Using AFL-gcc to compile fdc.c [moony add real command] Step 2: Designing input case file format One input case file contains several commands struct fdc_command { unsigned char cid; unsigned int args_count; unsigned int args[0]; }; The field cid is the floppy disk controller command ID. As I mentioned above , the structures will be translated to MIOA requests. Step 3. We prepare 30 input case file (one case input file for each floppy disk control command) Step 4: Preparing DCC Parsing input case file and translating to MIOA requests. Fork VSP , using following commands: mkfifo jack_pipe mkfifo jack_pipe1 qemu-system-x86_64 -bios out/bios.bin -serial pipe:jack_pipe -serial pipe:jack_pipe1 The bios.bin is CBS . Open pipe, and write MIOA requests to pipe and read response from pipe. Wait the VSP ‘s pid. Step 4: Using commands to start testing. afl-fuzz -t 99000 -m 2048 -i IN/ -o OUT/ <DCC command> In our testing environment (8G ram, 4 cores CPU), running the solution about 1.5 hours, we reproduce the Venom vulnerability on the QEMU 2.3.
- #43 http://venom.crowdstrike.com/ http://www.slideshare.net/CanSecWest/csw2016-tang-virtualizationdevice-emulator-testing-technology http://lcamtuf.coredump.cx/AFL/ https://www.youtube.com/watch?v=O9P7kXm5WSg Filesystem Fuzzing with American Fuzzy Lop https://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing,%20Vault%202016_0.pdf Triforce-run-afl-on-everything https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2016/june/project-triforce-run-afl-on-everything/ https://www.seabios.org/SeaBIOS https://www.seabios.org/Execution_and_code_flow http://wiki.qemu.org/Features/QTest http://www.intel.com/content/www/us/en/io/universal-serial-bus/extensible-host-controler-interface-usb-xhci.html http://wiki.osdev.org/Floppy_Disk_Controller