Trapfuzz - SIGBUS Error in Honggfuzz about p0tools HOT 5 CLOSED

@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

from p0tools.

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?

from p0tools.

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.

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)

from p0tools.

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

from p0tools.

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

from p0tools.