what you corrupt is not what you crash challenges in
play

What You Corrupt Is Not What You Crash: Challenges in Fuzzing - PowerPoint PPT Presentation

What You Corrupt Is Not What You Crash: Challenges in Fuzzing Embedded Devices Marius Muench 1 Jan Stijohann 2 , 3 Frank Kargl 3 elien Francillon 1 Davide Balzarotti 1 Aur 1 EURECOM 2 Siemens AG 3 Ulm University Introduction Embedded


  1. What You Corrupt Is Not What You Crash: Challenges in Fuzzing Embedded Devices Marius Muench 1 Jan Stijohann 2 , 3 Frank Kargl 3 elien Francillon 1 Davide Balzarotti 1 Aur´ 1 EURECOM 2 Siemens AG 3 Ulm University

  2. Introduction • Embedded devices are becoming increasingly more important • Vulnerabilities go beyond misconfigurations, weak authentication, hard-coded keys, etc. • Fuzz testing is a popular and effective method for uncovering programming errors • A variety of work improves input generation and fault detection for fuzzing 1

  3. Problem Statement How efficient are we at fuzzing embedded devices? Can we do it better? 2

  4. Fuzzing, Corruptions & Crashes

  5. Starting Point Corruption � = Crash 3

  6. Embedded Devices: A minimalistic classification Type-I: Type-II: General purpose OS-based Embedded OS-based Type-III: No OS-Abstraction 4

  7. Challenge #1: Fault Detection • Lack of basic features, such as: • Memory Management Unit (MMU) • Heap consistency checks • Canaries • Often only solution: Basic liveness checks 5

  8. Challenge #2: Performance & Scalability • Fuzzing greatly benefits from parallelization • This would mean 1 device per instance • Frequent restarts are required • Fast for software, slow for full systems 6

  9. Challenge #3: Instrumentation • Hard to retrieve coverage information • Tools for turning silent corruptions into observable ones rarely available • Unsupported instruction set architecturess • Operation tied to OS-specific features 7

  10. Measuring the effect of memory corruptions • Five common types of memory corruptions • Insertion of artificial bugs in two popular open source programs • Expat • mbedTLS • Trigger condition inspired by LAVA [1] • Vulnerable programs are compiled for four different devices [1] Dolan-Gavitt, Brendan, et al. ”Lava: Large-scale automated vulnerability addition.” IEEE Symposium on Security and Privacy (SP), 2016. 8

  11. Effects of Corruptions accross different systems Platform Desktop Type-I Type-II Type-III Format String ✓ ✓ ✗ ✗ ! ✓ Stack-based buffer overflow ✓ ✓ (opaque) (hang) ! Heap-based buffer overflow ✓ ✗ ✗ (late crash) ✗ Double Free ✓ ✓ ✗ (malfunc.) ✓ ✗ Null Pointer Dereference ✓ ✓ (reboot) (malfunc.) 9

  12. Possible Directions for Improvement • Static Instrumentation • Binary Rewriting • Pysical Re-Hosting • Full Emulation • Partial Emulation • Hardware-Supported Instrumentation 10

  13. Possible Directions for Improvement • Static Instrumentation • Binary Rewriting • Pysical Re-Hosting • Full Emulation • Partial Emulation • Hardware-Supported Instrumentation 10

  14. Leveraging (partial) emulation to improve fuzz testing

  15. Set-up: Overview Avatar 2 boofuzz PANDA Embedded Device Fuzz Inputs Analysis Emulation MMIO Peripherals Plugis Figure 1: Setup for fuzzing utilizing partial emulation Code will be available at: https://github.com/avatartwo/ndss18_wycinwyc 11

  16. Set-up: Target • The vulnerable expat program, as seen in the last part • Focus on a Type-III device • Fuzzed in four different configurations 12

  17. Set-up: Native Avatar 2 boofuzz PANDA Embedded Device Fuzz Inputs MMIO Peripherals Analysis Emula � on Plugis 1. Native (NAT) 2. Partial Emulation with Memory Forwarding (PE/MF) 3. Partial Emulation with Peripheral Modeling (PE/PM) 4. Full Emulation (FE) 13

  18. Set-up: PE/MF Avatar 2 boofuzz PANDA Embedded Device Fuzz Inputs MMIO Peripherals Analysis Emula � on Plugis 1. Native (NAT) 2. Partial Emulation with Memory Forwarding (PE/MF) 3. Partial Emulation with Peripheral Modeling (PE/PM) 4. Full Emulation (FE) 14

  19. Set-up: PE/PM Avatar 2 boofuzz PANDA Embedded Device Fuzz Inputs MMIO Peripherals Analysis Emula � on Plugis 1. Native (NAT) 2. Partial Emulation with Memory Forwarding (PE/MF) 3. Partial Emulation with Peripheral Modeling (PE/PM) 4. Full Emulation (FE) 15

  20. Set-up: FE Avatar 2 boofuzz PANDA Embedded Device Fuzz Inputs MMIO Peripherals Analysis Emula � on Plugis 1. Native (NAT) 2. Partial Emulation with Memory Forwarding (PE/MF) 3. Partial Emulation with Peripheral Modeling (PE/PM) 4. Full Emulation (FE) 16

  21. Set-up: Fuzzer • boofuzz [2], a python-based fuzzer based on Sulley • Configured to trigger the corruptions with different ratios • Used for 100 fuzzing sessions over one hour each [2] https://github.com/jtpereyda/boofuzz 17

  22. Set-up: Corruption Detection Avatar 2 boofuzz PANDA Embedded Device Fuzz Inputs MMIO Peripherals Analysis Emula � on Plugis 1. Native (NAT) 2. Partial Emulation with Memory Forwarding (PE/MF) 3. Partial Emulation with Peripheral Modeling (PE/PM) 4. Full Emulation (FE) 18

  23. Set-up: Corruption Detection Avatar 2 boofuzz PANDA Embedded Device Fuzz Inputs MMIO Peripherals Analysis Emula � on Plugis 1. Native (NAT) 2. Partial Emulation with Memory Forwarding (PE/MF) 3. Partial Emulation with Peripheral Modeling (PE/PM) 4. Full Emulation (FE) 19

  24. Set-up: Corruption detection • 6 simple heuristics, monitoring the execution: 1. Segment Tracking 2. Format Specifier Tracking 3. Heap Object Tracking 4. Call Stack Tracking 5. Call Frame Tracking 6. Stack Object Tracking 20

  25. Measuring Fuzzing Throughput No Heuristics: Native Partial Emulation/Memory Forwarding Partial Emulation/Peripheral Modeling Full Emulation 10 4 Combined Heuristics: Partial Emulation/Memory Forwarding' Partial Emulation/Peripheral Modeling' #Inputs Full Emulation' 10 3 10 2 0 5 10 Corruption Ratio [%] 21

  26. Discussion, Future Work & Conclusion

  27. Insights from the experiments • Liveness checks only is a poor strategy • Full emulation is good - but rarely possible • Partial emulation can already help • But introduces significant performance overhead 22

  28. Limitations and Future Work • We focused on improving fault detection • Other challenges of fuzzing (e.g., input generation) not addressed in this work • Our experiments focused on artificial vulnerabilities • Good for improving our initial understanding • We investigated solutions based on partial emulation • Other approaches still open for research 23

  29. Conclusion • Fuzzing embedded devices requires a paradigm shift • (Partial) emulation can improve fault detection • We need good emulators • Fuzzing of embedded devices needs more investigation 24

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend