Fuzzing 0x01 - libFuzzer, clang and Honggfuzz
ฝัง
- เผยแพร่เมื่อ 12 ก.ค. 2020
- Fuzzing 0x01 notes and video.
It covers the basics of clang, and how it implements the LLVMFuzzerTestOneInput interface, how the compiler uses this symbol, and Honggfuzz.
Notes drive.google.com/file/d/1jW96...
For security training or consultancy, please visit us at - www.codalabs.uk.
If you'd like to keep informed of upcoming material, training sessions or blogs, feel free to follow me on LinkedIn - / chris-cyber-researcher . Or if you'd prefer email updates, you can sign up to our mailing list - eepurl.com/g37-YX
excellent
I had a go at fuzzing XML and JSON parsers with dictionaries. For JSON with one seed file, I got 100k cashes 1 unique after 5 mins of fuzzing. Does having loads of non-unique crashes make fuzzing pointless because you're hitting the same code blocks and then crashing with the same bug. My coverage was going up slowly. So at this point would you give up fuzzing that target and move on or am I just being impatient?
It doesn't make it pointless, but you need to bear it in mind.
I talk a lot about fuzzing without sanitizers on first, otherwise, you'll more likely trigger lesser bugs before finding major ones. There's also a possibility that you keep hitting some critical vulnerability, e.g. a DoS, but right next to it is an RCE. You can't get around that without fixing the code via binary patching, or updating code as you go.
Ideally, it would be part of an SDLC/CI/CD pipline where you can throw more simple bugs back at the developers for quick fixes. Slow coverage can be down to several things, bad initial corpus, a shallow program, bad test harnesses, bugs getting in the way, anti-fuzzing code. To solve it you can create better initial corpus', fuzz more complex programs, write richer and more test harnesses, or use other techniques such as SMT/ML to help.
At this stage the whole process becomes a bit of an art, which you just need experience with.
Thank you for your great work!
Unfortunately, you haven't shown how to build shared object libraries (.so) with instrumentation features from 31:55.
The code is within the Makefile in the honghfuzz directory. It just replaces the entire compiler with hfuzz-clang and gets instrumented that way.
Thank you, Chris! Am I right, that all these libraries are built each time we launch the make file?
Can I ask you to clarify the final moments 1:01:34 - Do we need to separately build the libraries with instrumentation features apart from the test file (-o test) or we need to build only the test file?
@@IgorKorkin for instrumentation you can do both. It's a bit weird but it works.
If you only instrument the test harness you'll only be gaining coverage information in the test binary. But you will still be sending data to the library, it just won't affect the coverage -- it's pretty pointless to run it this way.
If you only instrument the library then you won't trace the test harness, but you will trace the library. You'll fuzz both, but most importantly you'll be getting coverage within the library. This is a much better scenario than the first, but the basic approach is to instrument everything you want to test, including the test harness.
There might be legitimate reasons not to instrument something. For example, you want to attack an XML parsing library, but that library depends on another one, e.g. pretty printer library. You don't care about fuzzing the pretty printer and thus don't instrument it.
It can reduce your iterations significantly and it only really matters if you're building everything, including the pretty printer. In most cases it's okay to instrument the target library and test harness only.
@@chrispowell1224 Thank you for your answer.
For example, I'd love to fuzz openssl-1.0.1f (github.com/google/fuzzer-test-suite/blob/master/openssl-1.0.1f) and I'm confused with a big picture.
Using their build.sh script I can build all files with instrumentation: openssl-libraries' files and a target.cc file.
After that, I've changed the target.cc file.
What should I do now? Should I again build all files using their build.sh or I can only build an updated target.cc file.
The thing is that building the openssl-libraries' files with instrumentation takes more than 2 minutes. Maybe it is possible to build libs files once without repeating each time and save time.
Thank you!
@@IgorKorkin if you only change target.cc you only need to re-build that. You don't have to re-compile everything, the instrumentation will still work.