Fuzzing a kernel (x86_64 and POSIX Compliant) using TriforceAFL

[Deoxyss]

I'm trying to fuzz the emulation of QNX on QEMU-support using TriforceAFL

So, for fuzzing, I use:

./afl-fuzz -t 500+ -i inputs -o out234 -QQ -- \
 ./afl-qemu-system-trace \
 -m 256M \
 -L qemu_mode/qemu/pc-bios \
 -drive format=raw,file=ifs.img \
 -drive file=fs.img,format=raw \
 -kernel bzImage 
 -aflPanicAddr ffffffff8108ea0c \
 -aflDmesgAddr ffffffff810f32e0 \
 -aflFile @@

Here,

• fs.img and ifs.img are the filesystem and image-filesystem disk files used to boot QNX on QEMU
• I modified afl-qemu-system-trace from QEMU emulator version 2.3.0 to QEMU emulator version 2.11.1 (older version was not able to boot qnx)
• bzImage is procnto-smp-instr (as kernel is the process with PID of 1)
• Panic and Dmesg are used accordingly

Also, to test the emulation of QNX, I'm using:

./afl-qemu-system-trace \
 -m 256M \
 -L qemu_mode/qemu/pc-bios \
 -drive format=raw,file=ifs.img \
 -drive file=fs.img,format=raw \

This boots QNX on QEMU

But, when I run the above afl-fuzz command, it gives the following error:

[-] Hmm, looks like the target binary terminated before we could complete a
    handshake with the injected code. There are two probable explanations:


    - The current memory limit (2.00 GB) is too restrictive, causing an OOM
      fault in the dynamic linker. This can be fixed with the -m option. A
      simple way to confirm the diagnosis may be:


      ( ulimit -Sv $[2047 << 10]; /path/to/fuzzed_app )


      Tip: you can use http://jwilk.net/software/recidivm to quickly
      estimate the required amount of virtual memory for the binary.


    - Less likely, there is a horrible bug in the fuzzer. If other options
      fail, poke <[email protected]> for troubleshooting tips.


[-] PROGRAM ABORT : Fork server handshake failed
         Location : init_forkserver(), afl-fuzz.c:2123

I'm still not able to figure out why it fails. I tried changing the memory limit, but it wasn't effective.

afl-qemu-system-trace is the target binary here (Please correct me if I'm wrong).

Also, when used in user mode (-Q) instead of full-system emulation (-QQ), this executed for QNX and fuzzing process started!
i.e., in user mode (-Q), where afl-qemu-system-trace is qemu-system-x86_64 binary of QEMU emulator version 2.11.1

I read that qemu-system-x86_64 is used for full system emulation ( while qemu-x86_64 is for user mode emulation ) . Hence, afl-qemu-system-trace is for full-system emulation!

But here we are running full system emulation with -Q option (user mode) of afl !!!!

What does this mean exactly?

[richsurgenor]

This project uses QEMU 2.3.0, and requires the project specific AFL patches to work properly.

[jhertz]

Yes, this will only work with the provided version of QEMU.

If you're still interested, please move any discussion to https://github.com/timnewsham/TriforceAFL where we can try and provide support.

[zunlongzhou]

I'm trying to fuzz the emulation of QNX on QEMU-support using TriforceAFL

So, for fuzzing, I use:

./afl-fuzz -t 500+ -i inputs -o out234 -QQ -- \
 ./afl-qemu-system-trace \
 -m 256M \
 -L qemu_mode/qemu/pc-bios \
 -drive format=raw,file=ifs.img \
 -drive file=fs.img,format=raw \
 -kernel bzImage 
 -aflPanicAddr ffffffff8108ea0c \
 -aflDmesgAddr ffffffff810f32e0 \
 -aflFile @@

Here,

• fs.img and ifs.img are the filesystem and image-filesystem disk files used to boot QNX on QEMU
• I modified afl-qemu-system-trace from QEMU emulator version 2.3.0 to QEMU emulator version 2.11.1 (older version was not able to boot qnx)
• bzImage is procnto-smp-instr (as kernel is the process with PID of 1)
• Panic and Dmesg are used accordingly

Also, to test the emulation of QNX, I'm using:

./afl-qemu-system-trace \
 -m 256M \
 -L qemu_mode/qemu/pc-bios \
 -drive format=raw,file=ifs.img \
 -drive file=fs.img,format=raw \

This boots QNX on QEMU

But, when I run the above afl-fuzz command, it gives the following error:

[-] Hmm, looks like the target binary terminated before we could complete a
    handshake with the injected code. There are two probable explanations:


    - The current memory limit (2.00 GB) is too restrictive, causing an OOM
      fault in the dynamic linker. This can be fixed with the -m option. A
      simple way to confirm the diagnosis may be:


      ( ulimit -Sv $[2047 << 10]; /path/to/fuzzed_app )


      Tip: you can use http://jwilk.net/software/recidivm to quickly
      estimate the required amount of virtual memory for the binary.


    - Less likely, there is a horrible bug in the fuzzer. If other options
      fail, poke <[email protected]> for troubleshooting tips.


[-] PROGRAM ABORT : Fork server handshake failed
         Location : init_forkserver(), afl-fuzz.c:2123

I'm still not able to figure out why it fails. I tried changing the memory limit, but it wasn't effective.

afl-qemu-system-trace is the target binary here (Please correct me if I'm wrong).

Also, when used in user mode (-Q) instead of full-system emulation (-QQ), this executed for QNX and fuzzing process started! i.e., in user mode (-Q), where afl-qemu-system-trace is qemu-system-x86_64 binary of QEMU emulator version 2.11.1

I read that qemu-system-x86_64 is used for full system emulation ( while qemu-x86_64 is for user mode emulation ) . Hence, afl-qemu-system-trace is for full-system emulation!

But here we are running full system emulation with -Q option (user mode) of afl !!!!

What does this mean exactly?

Please tell me how the ifs.img fs.img bzImage you mentioned is generated, I am a beginner in qnx and I can never google the answer to the generation of image files