Avast Antivirus, now with free remote reset option.
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 and because that software tends to hook into lots of places in the OS so if a backdoor is found you are immediately in big trouble.
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.
And I guess non-glued usb ports on every computer.
And users that put every USB stick in their computer they are handed by strangers in front of the office. Or they find on the printer. Especially when labeled "Pictures".
Because
CEO: Have we Antivirus installed?
CIO: Yes.
Not
CEO: Are we secure?
How does your risk analysis look like?
Do we internal or perimeter defense?
CIO: ...
I have never seen a company, large or small, which disabled USB ports. Because convenience is always higher rated than security.
Glueing is much easier, can't fail with wrong configurations or roll outs, works if people have too many permissions on Linux and in a myriad of other ways.
You've never worked a large bank. They get attacked all the time, every day, over the network, with social engineering (dropping infected USB drives in the parking garage), and plain old physical theft and con-artistry. Moving any file on or off their system is a huge pain (e.g., e-mail attachments are automatically removed unless you go through a security process).
Great to hear there are companies that take security seriously.
The companies I've consulted with had USB not secured in the Laptops of the marketing departments I've seen - and yes some of them lost several hundred millions of $ b/c of breaches in revenue.
"We have a password policy in place that forces our users to change their passwords to something long and random with lots of symbols in it no less than 50 characters every week - we're on the cutting edge of security!"
Adobe deserve a pile of the blame here for the pdf spec - it only requires the magic to appear in the first 1024 bytes[1] (and that %EOF appears in the last 1024) - thus allowing silly tricks like PDFs that are also another file type [2].
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.
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.
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.
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).
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.
Do you have description on the procedure of how you did all this by chance (especially, how did you get that graph[0])? I'm interested in reverse engineering, but can't find many good starting points to do it myself. And congrats on your achievement, we need more people like you, who put such shoddy programming practices in broad daylight, especially made by the companies that are supposed to make us safer.
The graph is generated by binary ninja [1] fully automatically, and this is just a screenshot of the tool. Any alternative reversing platform or disassembly tool like IDA Pro can generate you something very similar.
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.
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.
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.
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.
I am a novice programmer and as novice programmers go, I am interested in everything tech and coding as much as I can understand. Takes a while to understand but uniquely interesting.(Read - never read something in this field)
It could prevent a part of the problem, depending on how Avast chooses to parse things.
Remote execution would be harder to achieve.
But, parsing anything that you end up evaluating includes a whole class of bugs that Rust can't reason about.
A common (terrible) example on Windows is to serialize a data structure, and then pass it to another program after forking to a new process. If that serialized data includes particular sequences, it can cause the forking process to do other things.
Rust can help you ensure memory safety, and type safety. But it doesn't prevent stupidity.
There are no rules written about novelty accounts in either the guidelines or the FAQ. I'm not a fan either and they're just downvoted anyway. But what rule are you referring to?
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 and because that software tends to hook into lots of places in the OS so if a backdoor is found you are immediately in big trouble.