I wanted to find a program to practice using AFL on and decided to settle on the "pattern matching swiss knife for malware researchers", Yara.
After a few days of fuzzing, I found two heap overflows, however I did not try to pursue exploitation. The rest of the unique crash cases came from divide by zero errors.
Overall, the response by the developer behind Yara was extremely effective. I had initially intended to only send him one crashing input, ask him to fuzz/search on his own, and wait to see how many of our crashing inputs matched before sending the rest, but since he had found & patched the underlying flaw for the first crash within hours, I decided to just send him everything.
At 2015-06-29 10:19 PM EST, I wrote:
I started fuzzing yara with American Fuzzy Lop and found many input rule files that cause yara v3.4.0 to crash.
Most are harmless floating-point exceptions but some are possibly more serious (segfaults / heap stack overflows / etc.). This would affect anyone who accepts and runs yara scans with arbitrary rule files (I have a website that does this and, depending on how VirusTotal uses its users' yara rules, VT may be affected as well).
I'm just starting to triage the results to see if any look exploitable, but I was wondering if you've looked into fuzzing yara before or are familiar with AFL. Triaging would be much easier with the help of someone familiar with the codebase.
Here's one example you can try out now (attached). For me, running any query with this rule file or just compiling with yarac causes a segfault (for both released v3.4.0 or master branch on git).
ex: "yara segfault.yara ./" or "yarac segfault.yara out"
At 2015-06-30 5:33 AM EST, I received a reply:
Actually I haven't looked into fuzzing yara, but a think it's a good idea. If you send me those files causing crashes I can take a look and fix the bugs. This one is fixed in the latest commit (https://github.com/plusvic/yara/commit/cf4746dd2228d22aa961e67c8447e90c6917a14d)
At 2015-06-30 11:29 AM EST, I wrote:
Wow, that was quick! Here's a .tar.gz of all the crashes I've found so far (attached).
The input test cases are in input/, and ASAN-information.txt contains information about what happened in each case. AFL does its best to try to "unique-ify" the input crash files, but I haven't re-tested these with the latest code from github yet.
All except a few of these were found by fuzzing with ASAN turned off, so I'd expect there'll be a few more cases that pop up when ASAN is turned on while fuzzing.
Do you know if VirusTotal is covered by any of Google's bug bounty program? (Or does VT have one of its own?)
At 2015-06-30 11:37 AM EST, I received a reply:
Great! I'm going to look at this and try to fix any potential issue. I'm also playing a little bit with American Fuzzy Lop to try to find some more crashes.
As far as I know VirusTotal is not covered by any of Google's bug bounty program, and we don't have our own.
At 2015-06-30 11:59 AM EST, I wrote:
Ok, sounds good. In my case, it took AFL a few hours to start finding anything.
I can send more detailed stats / info about my scanning set up if you have issues reproducing what I found.
At 2015-06-30 3:08 PM EST, I received a reply:
I've fixed two additional bugs: the floating-point exceptions (which were caused by divisions by zero) and the heap overflow.
The heap overflow doesn't seem to be exploitable, as the user can't control the overwriting data.
Your information has been very valuable, thank you for your contribution!
A list of commits that contained fixes:
yara/commit/ cf4746dd2228d22aa961e67c8447e9 0c6917a14d
yara/commit/ 2bd7c65d41944e704b8c16aa06425a 859579e9d0
yara/commit/ c666ae1e1a4ecfc1eb536f6aa1b58f 3305b6679c
yara/commit/ 6fff18a475cf021b273156342ef434 82a7f7f7f6