hckrnws
My 5 cents on fuzzing compilers, and, actually, finding issues [1], also share another work we have done using black box/pentesting security techniques, including fuzzing in Fireblocks [2].
[1] https://www.coinfabrik.com/blog/why-the-fuzz-about-fuzzing-c...
[2] https://www.coinfabrik.com/blog/fireblocks-api-black-box-rev...
More on compiler correctness in general: https://github.com/MattPD/cpplinks/blob/master/compilers.cor... and fuzzing in particular: https://github.com/MattPD/cpplinks/blob/master/compilers.cor...
This is a great collection, thank you. :)
I was just reading about these whacky German's yesterday, after investigating a particularly undescriptive (and still available 20 years after it's last update) PKG in pacman. It was the tool/framework/concept that these guys used in the mid to late 90s to fuzz those 2k+ bugs out of Netscape Navigator like they mention in the article. Rather ingenious that it's fuzzing technique allowed them to not only isolate bugs without really knowing what behavior triggered it, but it would automatically narrow it down to the specific line of code at fault. I'm not really doing it justice, even less so because I can't remember the name of that tool/framework/technique.... Definitely made me rethink my understanding of how under lying systems architecture and code actually interact, and what a "bug" truly is. So anyway, tl;dr, a coincidence happened to me.
You might want to take a look at jsfunfuzz[0][1] or this USENIX paper[2] by Christian Holler, Kim Herzig and Andreas Zeller, called "Fuzzing with Code Fragments" (which also references [0]; two of the paper's authors contributed to the fuzzing book).
Based on your description and the overlap in authors, LangFuzz, as presented in the paper, seems to match quite close. Roughly summarizing a few paragraphs of the paper, they mainly used a mutational approach (e.g. modifying already found/generated "inputs") after a learning phase where sample files are processed and their grammar discovered (section 3.1 in [2]). This leads to code fragments that are syntactically correct, but might be semantically incorrect (see section 3.3 in [2])
Another fuzzer (albeit more recently in time) that has found numerous vulnerabilities is afl-fuzz, or "american fuzzy lop"[3].
[0] https://www.squarefree.com/2007/08/02/introducing-jsfunfuzz/
[1] https://blog.mozilla.org/security/2007/08/02/javascript-fuzz...
[2] [PDF] https://www.usenix.org/system/files/conference/usenixsecurit...
An API fuzzer I've been building for several years now: https://github.com/Endava/cats
There's also Fuzzing 101: https://github.com/antonio-morales/Fuzzing101
It's pretty cool how the site looks gorgeous and even has working menus without any JavaScript.
Great content, excited to see the book grow :)
Agreed - the authors are the top fuzzing experts.
Crafted by Rajat
Source Code