Saturday, August 1, 2015

Reporting Crashes in Yara to Victor Alvarez/VirusTotal


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:

Hi Victor,

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:

Hi Andy,

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 (


At 2015-06-30 11:29 AM EST, I wrote:

Hi Victor,

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:

No comments:

Post a Comment