How I Luckily Crashed Vim in 5 Minutes

#testing #security #c #cybersecurity

Hi! It's me again with my boring posts that no one like 😌

Today, I would like to share a recent finding which involves fuzzing. I am learning general concepts of binary fuzzing, started on Christmas Eve, and just a few days after starting that, I already was lucky of finding a bug in the text editor Vim.

🏞️ Motivations

While looking at Huntr's Hacktivity, I noticed many different reports of more "low-level" issues such as Buffer Overflow, Out-of-bounds Read, Use After Free, etc.

Some of them mentioned the word "fuzzing", and I was definitely not familiar with this concept, at least not when it comes to looking for issues that cause segmentation faults. The only fuzzy thing I knew was basically that brute forcing method for finding directories of a website or subdomains of a given root domain.

So I found this video of LiveOverflow, which shows AFL being used in an attempt to reproduce a security flaw in sudo through fuzzing.

🚧 Learning Begins

Although this video made me know that it is possible to test binaries with a more automated approach, I still couldn't get how exactly I was supposed to do so. For some reason, when I am learning something new, I need examples where I can execute it by myself.

So I came back to those reports, and saw that new ones were disclosed. Octavio Gianatiempo had reported some issues in Vim, and I decided to contact him, in order to see if I could get some insights. Luckily, besides some really good materials which I am going to be putting in the end of the post, he had exactly what I was looking for, a repository with challenges and solutions involving fuzzing. This repository is called Fuzzing101.

This made me start my studies, and it's been actually really nice because Fuzzing101 picks real vulnerabilities that already have CVE IDs and shows you how to find them by fuzzing. Also, you always have the possibility of finding new ones and reporting them.

🧐 Let's fuzz Vim...wait, already?! 😱

After solving up to the Exercise nº 3 of Fuzzing101, I was wondering:

Why don't I just try to apply the same concepts on Vim?

And that's what I did! I picked up a PoC of a previously reported and fixed issue, and used it as valid input for AFL++ to do its magic with all my CPU cores.

I wasn't even expecting it to find anything, because I was taking hours to find crashes in the exercises, but surprisingly, only 5 minutes later, AFL++ found a crash! 🥳

The crash was caused by a Double Free, and it happened quickly because that specific PoC served as a really good input file, which ended up helping AFL++ to find a similar problem in a different part of the code.

You guys can find the report with more details here.

It is worth mentioning that not always we are going to find issues in a few minutes, neither in a few hours, neither in a few days. It all depends in a lot of factors, and that is what makes me think I was lucky.

✏️ Lessons Learned

When you are learning something new, asking for directions to someone who had already been in your situation might help a lot (just know what exactly you want before asking questions, I've seen that a lot of people don't like those generic ones);
Just because an issue received a fix, doesn't necessarily mean it's fixed 🥴. We've seen something similar to that, last year, with Apache's CVE-2021-41773 and its variants. In the case of this Double Free, the new input triggered the same type of issue in a different part of the code, that was not directly related to the previous flaw;