Blowing the Cover of Android Binary Fuzzing

Transcript

1. RWCTF Tech Forum, 2021 Blowing the Cover of Android Binary

   Fuzzing Flanker Senior Researcher, Pangu Team

2. About me • Senior Security Researcher at Pangu Team •

   Three-time Pwn2Own winner, Master of Pwn at 2016 & 2017 • Pwnie Best Client Bug & Best Privilege Escalation Bug Nominations • Speaker at Blackhat, DEFCON, CanSecWest, RECON, HITCON, QMSS, PoC, MOSEC • Committee of GeekPwn

3. Agenda • Introduction and Background • Android Binary Fuzzing methods

   • Real world actions

4. Introduction and Background

5. State-of-the-art Fuzzing • Fuzzing need some sort of "feedback" •

   de facto standard of modern fuzzing: Coverage-Guided (CGF) • coverage information is the key • compiler instrumentation w/ source code (GCC, LLVM) • hardward-based: processor trace • binary-based: static rewrite/ dynamic tracing (!)

6. State-of-the-art Fuzzing • Fuzzing need some sort of "feedback" •

   de facto standard of modern fuzzing: Coverage-Guided (CGF) • coverage information is the key • compiler instrumentation w/ source code (GCC, LLVM) • hardward-based: processor trace • binary-based: static rewrite/ dynamic tracing (!)

7. State-of-the-art Fuzzing: CGF (cont.) • Fuzzer identi f i es

   constrains automatically • Reduce e f f ort for manual structure discovery • Of course still helps if you have time (AFL-libprotobuf, AFL-Peach) • AFL: the supreme leader

8. AFL w/ compiler instrumentation • Record coverage edge transfers in

   shared mem cur_location = <COMPILE_TIME_RANDOM>; shared_mem[cur_location ^ prev_location]++; prev_location = cur_location >> 1; • Inputs that triggers new local_state is added to Q • compared and overwrite virgin_bits

9. CGF w/o compiler support? • The real dragon • Third

   party SDKs • Platform proprietary binaries (Qualcomm, Samsung, Apple, etc) • Heterogeneous complex binaries • products too big/ too old/ too di f f i cult to recompile even with source • products need emulation support

10. Despite the need however • Few real-world cases have been

    discussed • Especially for mobile binaries • Fill the gap between theory and action • with real cases/ real bugs

11. On the shoulders of giants

12. First things first Static rewrite or dynamic tracing?

13. Static rewrite • Instrument binaries statically to • … inserting

    callbacks for each basic block and an initialization callback either at _init or at speci f i ed entry point … • AFL-dyninst • Pros: • minimal runtime overhead • Cons: • incomplete disassembling (!): function rewrite/relocation • ELF compatibility

14. Static rewrite for Android binaries • arm/aarch64 support is immature

    • runtime crashes, incomplete coverages… • computing power on phones vs servers • overheating, slow perfs, physical bricks… • Conclusion: • not an acceptable solution (rewriting arm binaries and runs on arm devices) • ARM server comes to rescue?

15. Dynamic tracing: QEMU approach • QEMU provides dynamic binary translation

    via TB (Translated Block) • TCG (Tiny Code Generator) as IR • Target Machine Code -> • Frontend -> Ops -> Backend • -> Host Machine Code

16. Dynamic tracing: QEMU approach (cont.) • Coverage collection via TB

    hooking: tb_ f i nd_slow • a f l _maybe_log: … a f l _area_ptr[cur_loc ^ prev_loc]++; …

17. Dynamic tracing: QEMU approach (cont.) • Dup translate request to

    parent process • when a new block is encountered

18. Dynamic tracing: QEMU Full Mode (cont.) CPU Emulation JIT Soft

    MMU IO Interfaces Peripheral Model& Memory Flow control

19. Dynamic tracing: QEMU user-mode (cont.) CPU Emulation JIT Soft MMU

    IO Interfaces (Translated & Forwarded to Host OS) Peripheral Model& Memory (Partially Translated & Forwarded to Host OS) Flow control Kernel (Host Kernel)

20. Dynamic tracing: QEMU unicorn (cont.) CPU Emulation JIT Soft MMU

    IO Interfaces (Impl needed part, i.e. syscalls & ) Peripheral Model& Memory (Impl if needed) Flow control Kernel (Provided Kernel)

21. Dynamic Tracing: TLDR • Unicorn provides a raw interface to

    run machine code • runs arm code at given memory address of given content • provides callback and memory interfaces • user need to impl syscalls / ELF initialization loading • QEMU-user reuses host OS env • translate & forward syscalls to host kernel

22. Applied fuzzing with Android QEMU on x86 server

23. DEMO1

24. QEMU optimization • TB chaining is disabled in AFL-QEMU and

    unicorn • chained TB does not jump back to a f l _maybe_log, misses coverage • *Solution: move coverage to TCG generation • TB chaining info optimization does not pop back to fork server • *Solution: cache patched jump slots • Use custom emulation to improve speed (DroidCorn, MOSEC 2020) • Reference: [1]abiondo

25. DroidCorn Arch • A C++ *framework* that wraps arbitrary ARM/AARCH64

    binary and turns it into fuzzable x64 target for AFL, runs on arbitrary platform Processor Tracer Unicorn Engine (Patched) Forkserver Mini Kernel Syscall Handler Memory Layer Mini Runtime ELF Linker MiniHeap MiniHooker Crash Triager Trace Recorder Symbolizer

26. DroidCorn Optimization: Conclusion • o f f l oad hot

    library work to host side • reduce unnecessary syscalls and complex library functions (also protects syscalls) • driver emulation • better control over code tracing and process inspection • runs everywhere • Numbers: • ~15x perf boost compared to other python versions • ~30% perf boost compared to qemu-user (if applicable) • Details refer to my talk at MOSEC 2020

27. Case study

28. The image library bundled in billions of Samsung phones Quram

29. Attack surface locating • Natalie from Google Project Zero f

    i rst posted an entry at 2015 • which caught my attention since then • Unexpected still remain hidden from public even after ~5 years • P0 posted another entry this year (the only one), but from di f f erent perspective • A quite complex binary • with a lot codecs • in system partition

30. API reversing • A nature entry is the stock Gallery

    App • QuramCodecInterface is the Java wrapper for QuramCodec • Called by ImageDecoder.decodeFile • QuramCodec is called • if Codec is present • if inJustDecodeBounds is true • if ifPreferedQuramCodec is true

31. API reversing: libimagecodec.quram.so • For all image types: • some

    MIMEs are default to true • Other major types (JPEG, GIF, BMP, WBMP, PNG, etc) • Set to true in some threads • Thumbnail, FaceDetection, etc • Automatically triggered when f i le is added to inventory • otherwise delegate to SKIA (not interesting) • Receiving JPEG triggers the library (and its bugs in background silently)

32. API reversing • The JNI function accepts a f i

    lepath/bytearray, and returns an AndroidBitmap with pixels f i lled • Metadata is retrieved by QuramGetImageInfoFromFile (height/width/ f i letype) • Creates Bitmap based on metadata

33. API reversing • AndroidBitmap_lockPixels creates bu f f er depend

    on RGB type • Parsing dispatches to QrDecodeImage for di f f erent types • AndroidBitmap_unlockPixels f i nishes decoding

34. API reversing

35. API reversing: call flow JNI entry QuramGetImageInfoF romFile2 Creates AndroidBitmap

    and locks buffer returns Bitmap created QrDecodeImage writes to buffer

36. Whoa, DNG

37. API reversing DNG • DNG are f i rst-class Quram

    citizen • Not delegated to SKIA (if applicable) • Reveals quite a lot surfaces Incoming Image File Yes No Extension is DNG? QuramBitmapFactory. decodeFile No Yes? QrParseMetaData is valid? QuramBitmapFactory. decodeFile No Yes `make` field is Samsung? QuramBitmapFactory. decodeDNGPreview Quram GetImageInfo FromFile returns RAW? QrDecodeDNGFile

38. Creating Harness JNI entry QuramGetImageInfoF romFile2 Creates AndroidBitmap and locks

    buffer returns Bitmap created QrDecodeImage writes to buffer Harness

39. Creating DNG harness JNI entry QuramGetImageInfoF romFile2 QrParseMetaData returns Bitmap

    created QrDecodeDNGFile writes to buffer QrDecodeDNGFile

40. Creating Harness: Fuzzing!

41. Fuzzing! • Input cases: a f l _images • Running

    at ~200/sec per core, ~6000 per server • the outcome … •

42. Fuzzing! • Input cases: a f l _images • Running

    at ~200/sec per core, ~6000 per server • the outcome … • OOB read, write/ arbitrary free/ heap over f l ow/ FPE/ NPE … • Really shows security *does not* come from obscurity • Close-source does not protect it from vulnerability, with rather the opposite

43. Outcome: OOB write w/ controllable register

44. Outcome: heap overflows

45. Outcome: Corrupted Heap Structure

46. Outcome: bad free

47. Outcome: integer overflows

48. Crash triaging • QEMU does not re f l ect

    crash trace to host • Need a custom unwinder/backtracer • Memory sanitizers helps • libdislocator • QASAN

49. Vendor response • CVE-2020-12751, CVE-2020-25278, CVE-2020-12751 is assigned for all

    these issues • DNG crashes narrowed down to 11 sites and is con f i rmed and patching • Samsung does not agree that these are all high-severity vulnerabilities??? • Assigned CVE-2021-22493 • More awaiting con f i rmation

50. Upcoming work • Faster optimization • simplify callback costs •

    Force QEMU tb compile? AOT vs JIT • Incorporate AFLOPT • Coverage visualizer for IDA • Revealing more attack surfaces

51. DEMO: • Bv

52. None

53. References • https://abiondo.me/ • https://github.com/lunixbochs/usercorn • https://github.com/AeonLucid/AndroidNativeEmu • https://github.com/AFLplusplus/AFLplusplus •

    https://github.com/Battelle/a f l -unicorn • https://abiondo.me/2018/09/21/improving-a f l -qemu-mode • https://github.com/andrea f i oraldi/qasan • https://gts3.org/~wen/assets/papers/xu:os-fuzz.pdf • https://andrea f i oraldi.github.io/articles/2019/03/29/a f l -talk.html

54. Takeaways • CGF fuzzing on blackbox binaries • QEMU modes

    of fuzzing • Samsung Quram fuzzing and bugs

55. Thanks • Questions? • Twitter/Weibo: f l anker_017 • 微信公众号/Wechat

    Account