Trapfuzz - SIGBUS Error in Honggfuzz

[torque59]

Great work with the trapfuzz implementation. I was actually trying out to get the implementation running with the patch, the patch doesn't seem to work on honggfuzz latest 2.2 (API changes), so i switched to the honggfuzz repo (https://github.com/saelo/honggfuzz) by @saelo.

Now i run into SIGBUS errors, i obtained the patchpoints from ImageIO library and cross checked whether they are the correct offsets as well. I tried debugging the issue but couldn't somehow get it working. Does this have something to do with Shadow memory ?

System Configuration => MacOS : 10.15.4

The following is the error message as well:

SIGBUS.EXC_BAD_ACCESS.PC.00007fff315c09cf.STACK.00000000f1ece522.ADDR.00007fff71c0e836.fuzz' already exists, skipping

Am i doing something wrong here or missing something.

[saelo]

Hi! I'm unfortunately not really able to tell what is happening based on your description... The .fuzz file should indicate that Honggfuzz detected a crash and that this file triggered it. The already exists, skipping means it had found this exact crash before and so is discarding it. Also, SIGBUS.EXC_BAD_ACCESS sounds more like an access violation (i.e. segfault) rather than an int3 as used by Trapfuzz. What happens when you process that .fuzz file with runner.m outside of honggfuzz? Can you figure out what instruction in which library PC.00007fff315c09cf corresponds to (vmmap should be able to tell you the library mapped at that address)? Also, does Honggfuzz immediately and always produce this crash without ever successfully (i.e. without crashing) processing a generated sample?

[torque59]

Thanks @saelo for looking into this and sorry for the short description. Here's the detailed steps on what i did.

• Obtained the BB using binja and wrote to a file. Sample file on how it looks at the start below

  
  cat trapfuzz.patches | head -n3

/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO:0x12b000 0x1890 0x18a8

* Cloned and applied patches to honggfuzz (Ensured patches are in place as well).
* Copied testcases from https://bugs.chromium.org/p/project-zero/issues/detail?id=1952 (basically 2 tiff files orig.tiff and fuzz.tiff)
*  ```honggfuzz -W workspace --input input --output output --threads 12 --env TRAPFUZZ_FILE=trapfuzz.patches --env OS_ACTIVITY_MODE=disable --env DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib --rlimit_rss 4096 -- ./runner```

Honggfuzz immediately produces this same crash without ever successfully processing a generated sample and keeps on iterating over the same crash again.

![honggfuzz](https://i.imgur.com/qt6btWk.png)

As for the questions:
* The `.fuzz` does not produce a crash when testing with the tester.m (compiled as mentioned) outside of runner.m 

./tester ./workspace/SIGBUS.EXC_BAD_ACCESS.PC.00007fff315c09cf.STACK.00000000f189f641.ADDR.00007fff71c0e836.fuzz

2020-05-06 15:03:33.682 tester[80308:15342264] Image @ 0x60e0000010e0: <NSImage 0x60e0000010e0 Size={190, 143} Reps=( "NSBitmapImageRep 0x608000015b20 Size={190, 143} ColorSpace=(not yet loaded) BPS=8 BPP=(not yet loaded) Pixels=190x143 Alpha=NO Planar=NO Format=(not yet loaded) CurrentBacking=nil (faulting) CGImageSource=0x603000007450" )>

* `vmmap` for honggfuzz and the address seems to be loaded at javascript.core if i'm not wrong, with instruction

0x7fff315c09cf: 41 89 84 24 b0 00 00 00 mov dword ptr [r12 + 0xb0], eax

TEXT 00007fff30dbe000-00007fff30df2000 [ 208K 208K 0K 0K] r-x/r-x SM=COW /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/l ibTIFF.dylib TEXT 00007fff30df2000-00007fff30e08000 [ 88K 20K 0K 0K] r-x/r-x SM=COW /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/l ibTIFF.dylib TEXT 00007fff30e20000-00007fff312b0000 [ 4672K 132K 0K 0K] r-x/r-x SM=COW /System/Library/Frameworks/Intents.framework/Versions/A/Intents TEXT 00007fff312b2000-00007fff32352000 [ 16.6M 332K 0K 0K] r-x/r-x SM=COW /System/Library/Frameworks/JavaScriptCore.framework/Versions/A/Java ScriptCore

* `vmmap` for runner 

unused shlib DATA 00007fff315c0000-00007fff315c1000 [ 4K 4K 4K 0K] r-x/rwx SM=COW unused system shared lib DATA, on dirty page

* Yes Honggfuzz immediately and always produce this crash without ever successfully processing a generated sample (ran for an hour, it was iterating over the same SIGBUS ERROR)

[saelo]

Hmm that's curious. It would be the address in the runner, not the honggfuzz process. But the shared libraries are mapped at the same addresses across processes, so it should also be JavaScriptCore in the runner (which also doesn't make sense, it shouldn't execute anything from there). Two things you can try:

• Run with an empty (or almost empty) trapfuzz.patches file and see what happens
• Run runner.m with the trapfuzz instrumentation but compiled without honggfuzz so you can attach lldb and see what's happening. I think for that you mostly just need to copy the implementation of initializeTrapfuzz into the runner and replace this line https://github.com/googleprojectzero/p0tools/blob/master/TrapFuzz/runner.m#L44 with some bit of code that loads data from a file or uses a static buffer as input

[torque59]

@saelo sure, i'll try that and let you know.

[torque59]

@saelo i managed to figure out the problem, this is because ImageIO was a fat Mach-O binary and had multiple architectures and Binja by default loaded the wrong one, which led to loading wrong offsets for BB. I managed to extract the x86_64h of ImageIO using lipo and was able to get Trapfuzz working. Thanks for the help @saelo