Avast Antivirus Remote Stack Buffer Overflow with Magic Numbers

> I always hated anti virus packages both for the fact that AV vendors profit on something that shouldn't be required in the first place

You must hate a lot of things then.

The majority of customers I work with, that is part of the standard IT image, regardless which OS your computer might have.

I agree with the pdf spec allowing some insane stuff.

However, I think it's quite a stretch to put any blame on Adobe for this one.

In essence, Avast has implemented their own std::vec in C for the management of the magic numbers, and they implemented it quite poorly.

As mentioned in the article, the find_magicnums function supports roughly 300 (!) different magic numbers. Adobe's PDF is not required at all to exploit this bug.

Honestly, I'm quite surprised about the strong reaction. I thought it was common knowledge that this kind of software is full of bugs.

During the last year, I discovered dozens of bugs in different widespread anti-virus products. Not all of them can be as easily explained as this one and only a few a as critical as this one, but still...

Concerning your question: In general, I consider it quite difficult (if not impossible) to give a concrete answer. The software, as it is now, is just in a horrible state. Depending on what your threat model is, how experienced you are as a user, it might very well decrease your system security.

Yes. For organizations the harm is compounded because IT and users don't understand how limited AV is. They think AVs have good detection rate, and they think AVs can generally "disinfect" your computer when you get pwned, and think AV doesn't increase attack surface. This leads to the false conclusion that it's an acceptable risk to use Acrobat Reader and open attachments in Office etc.

My own thought process on this is the following: Some parts of antivirus software do good work. Understanding that antivirus software is no substitute for real security, but more like a helpful layer to try to catch things that otherwise might sneak in, helps a lot in using it successfully. On that level, software which scans downloaded files before opening them, and periodically scans the filesystem passively for any known threats, is not bad. I agree that patching the software of its bugs in the first place is a better goal, but it doesn't hurt to have an in-between option that helps out a little bit. Of course, such software rarely needs to be a third-party suite, as Microsoft's own Windows Defender software performs this task decently.

Where things get hairy are antivirus suites in particular. It's one thing to passively scan files, but AV suites have a bad habit of hooking into the operating system and making other changes, usually in the name of real-time monitoring. This is where I feel their supposed benefits fall flat. It would be one thing if these hooks were also passive, but Windows and most other operating systems make it difficult to access the kernel's data on purpose, and I don't trust an antivirus suite to do so in a safe manner. It's one thing for an exploit to compromise passive scanner running with userland permissions, and another thing entirely to exploit an AV suite with direct kernel access. The latter can cause the security features to backfire pretty hard.

>this is the second AV fiasco in recent months

First of all, this bug was fixed nine months ago (see Timeline).

This is in no way a "fiasco", this is normal process of improving security of the product. Bug reported and timely fixed, bounty paid, no exploit was found in the wild, no harm done. You can count yourself number of similar bugs fixed in Chrome or Firefox this year.

>is it safe to say that running an antivirus is actually increasing your risk instead of decreasing it?

Yes, running ANY software on your computer increases attack surface, thus increasing risks. In the same time running AV decreases many other risks.

My opinion is all in all AV still does more good then harm today, provided it's actively developed by credible shop and timely updated.

Erm, it seems you haven't been paying attention. This is the second AV fiasco in the last two days.

It's been the case for decades now. Guess the world is finally catching on.

Write parsing for complicated formats in C/C++. Run it on suspicious files from the outside world. What could possibly go wrong? Play stupid games, win stupid prizes.

In order to fight the virus you have to become like a virus in many ways. Like them, you have to hide your own code in order to avoid detection. You have to get down to their level and use dirty tricks.

It's more than the 2nd, and yes, it's safe to say that.

I'm sorry to disappoint you :)

I discovered this via a coverage based fuzzing engine with a dictionary (containing those magic numbers). Said fuzzing engine is similar to libFuzzer, but I have designed it with a focus on fuzzing closed source Windows binaries (PE).

Thanks for the question, I probably should have made this clearer in the article. Just presenting some pseudocode and typedefs of structs may have given a wrong impression of how this works.

So to be very clear: I reversed the functions and types without any symbols. All function names, type names, and variable names from the article are chosen by me. In the actual code, those names are most likely very different.

For such a simple function as this, all you need is the control flow graph form of X86 disassembly as linked in footnote 4 of the article.

In general you just disassemble, decompile, and then name things as you explore them and figure out what they do. Unless there are symbols available (which is rarely the case), the disassembler/decompiler will name things uniquely but not descriptively, e.g. func_117A508D or var_061B.

Addicionally ignore all the advices given by the Algol community since the 1960's, in spite of the fact the customers were more than happy with the output of their compilers.

Also, change your code often and hire/fire programmers at a high rate.

This is nowhere near the complexity and subtlety of crypto. Inserting into a sorted array is an elementary, computer-science-101 level task and I'd consider it to be not substantially more difficult than writing a correct FizzBuzz.

Then again, if you consider the number who fail at the latter, and how many would want to work on AV software anyway, it's no surprise things like this will happen.

The engine is not sandboxed. I will speak only for the Windows product though, because this is the only one I looked at in detail. (But the Linux engine is not sandboxed either).

This is X86 code [1] running as NT AUTHORITY\SYSTEM. Hence, successful exploitation for arbitrary remote code execution (as NT AUTHORITY\SYSTEM) only requires circumventing the stack canary.

As mentioned in footnote 6 of the article, they seem to use Control Flow Guard (CFG) on the latest Windows platforms. However, just as the stack canary, this is only a mitigation. It does not make exploitation impossible, it just makes it a bit harder.

[1] In the article, I present a pseudocode version of the relevant function. If you are interested in the actual X86 instructions, you might want to look at footnote 4 of the article.

Wow, thanks! That means a lot to me. Honestly, I didn't expect this to interest anyone.