Live data from Hacker News

Avast Antivirus Remote Stack Buffer Overflow with Magic Numbers

landave.io

31–40 of 56 posts

Re: Avast Antivirus Remote Stack Buffer Overflow with Magic Numbers

#32
post #12

this is the second AV fiasco in recent months. is it safe to say that running an antivirus is actually increasing your risk instead of decreasing it?

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.

Re: Avast Antivirus Remote Stack Buffer Overflow with Magic Numbers

#33
No one gets fired for installing Antivirus on every computer. From my experience enterprise IT is driven by checklist, looks good on paper, cover-my-* decisions. People are not interested in doing the right thing in large companies.

In one company every developer was forced on Antivirus without file exceptions making compilations a huge pain.

Re: Avast Antivirus Remote Stack Buffer Overflow with Magic Numbers

#34
post #12

this is the second AV fiasco in recent months. is it safe to say that running an antivirus is actually increasing your risk instead of decreasing it?

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.

Re: Avast Antivirus Remote Stack Buffer Overflow with Magic Numbers

#35

Take a lesson - always write parsers in C and then execute them as root, and be sure to send as much malicious content to them as possible. Bonus points for hooking it up to the internet.

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

Re: Avast Antivirus Remote Stack Buffer Overflow with Magic Numbers

#37

No one gets fired for installing Antivirus on every computer. From my experience enterprise IT is driven by checklist, looks good on paper, cover-my-* decisions. People are not interested in doing the right thing in large companies. In one company every developer was forced on Antivirus without file exceptions making compilations a huge pain.

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

Re: Avast Antivirus Remote Stack Buffer Overflow with Magic Numbers

#38

Couldn't they have avoided it by writing a type-safe parser in Rust?

avast is much older than Rust. The earliest presence on the web that I could find is from 1999 https://web.archive.org/web/19990203125025/http://www.avast....

In 1999, Ada, Modula-2, Object Pascal, Oberon could all have been an option.

Re: Avast Antivirus Remote Stack Buffer Overflow with Magic Numbers

#39
post #36

Is the scanning engine sandboxed in any way, or is the stack protector all there is between a scanner bug and a remote exploit?

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.

Re: Avast Antivirus Remote Stack Buffer Overflow with Magic Numbers

#40
post #26

This is probably a dumb question: but how does someone look at the source code for a commercial product like Avast? Some sort of DLL decompiler or something? If that is the case are things like function and variable names conserved? This is probably super trivial, but reverse engineering / pen testing isn't my area.

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.

Post reply on HN