Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

too many assert fail crashes makes the fuzzer unusable #2

Open
cutesmilee opened this issue Jun 28, 2021 · 2 comments
Open

too many assert fail crashes makes the fuzzer unusable #2

cutesmilee opened this issue Jun 28, 2021 · 2 comments

Comments

@cutesmilee
Copy link

Hi, the problem is that every time I run the fuzzer, after some minutes it crashes on this:

../fuzz/fakes/mbuf.c: assert failed on line 65: false
==4628== ERROR: libFuzzer: deadly signal
#0 0x10ed7ab35 in __sanitizer_print_stack_trace+0x35 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x51b35)
#1 0x10d5c7b72 in fuzzer::PrintStackTrace() FuzzerUtil.cpp:210
#2 0x10d575194 in fuzzer::Fuzzer::CrashCallback() FuzzerLoop.cpp:233
#3 0x10d57512d in fuzzer::Fuzzer::StaticCrashSignalCallback() FuzzerLoop.cpp:204
#4 0x10d5cf847 in fuzzer::CrashHandler(int, __siginfo*, void*) FuzzerUtilPosix.cpp:46
#5 0x7fff20677d7c in _sigtramp+0x1c (libsystem_platform.dylib:x86_64+0x3d7c)

NOTE: libFuzzer has rudimentary signal handlers.
Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal
MS: 1 CustomCrossOver-; base unit: 584c597c6031e0f4d0a1a5dbbce6261f450c47b6
0xa,0xa,0xb2,0x2,0x7,0x8,0x2,0x10,0x3,0x18,0x80,0x2,0xa,0x0,0x12,0x0,
\x0a\x0a\xb2\x02\x07\x08\x02\x10\x03\x18\x80\x02\x0a\x00\x12\x00
artifact_prefix='./'; Test unit written to ./crash-7ead9ed8b17c3dad664b1fdc83d19fa0981ecf54
Base64: CgqyAgcIAhADGIACCgASAA==

so I looked at the source to see if AddressSanitizer was enabled, and seems like so (from cmake and ninja files), can this be fixed, since this makes the fuzzer almost unusable.

@cutesmilee cutesmilee changed the title too many assert fail crashes too many assert fail crashes makes the fuzzer unusable Jun 29, 2021
@xsscx
Copy link

xsscx commented Jun 29, 2021

Hey-

That is normal... if you Distribute across a few VM's and run for a few hours you will get a larger corpus...

example... '197078 files found in corpus'

Matching the nm list against what is found Fuzzing and am learning how to tweak the config to induce more coverage..

Assumption is that the provided xnu source has been cleaned of Bugs and Google threw lots of CPU's at this Project so use it as an example...

In logs, look for things like ..

NEW_FUNC ....
.. in b_sum16 in_cksum.c
.. ip_stripoptions ip_input.c
.. in ifa_ifwithaddr if.c
.. in ifa_ifwithaddr_locked if.c
.. in iptime ip_icmp.c
.. in _OSSwapInt16 _OSByteOrder.h

Match against Functions in dylib to maintain coverage list....
...
libxnu.dylibicmp6_redirect_input libxnu.dylibicmp6_rip6_input
libxnu.dylibah4_input libxnu.dylibesp6_input_extended
...

Did some flame graphs a while back for example for the Call Stacks into Visual Graphs....

https://xss.cx/2021/04/26/img/sample-run-001-netfuzzer-libxnu.svg
https://xss.cx/2021/04/26/img/sample-run-003-netfuzzer-libxnu.svg

@cutesmilee
Copy link
Author

mmh will try, but isn't there a way to totally ignore stuff like asserts (for ignore I mean doesn't crash the fuzzer), and only catch memory corruption crashes?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants