Should I be shocked? Shouldn't I be? I'm currently shocked but I don't know if it's justified, not an expert in the field.
No, this is a principle limitation of any AV software that is based on blacklisting.
> Did no one come up with this before?
Of course other people came up with similar ideas before.
> Should I be shocked?
If and only if you had trust in your AV software before.
The main thing is to make sure you trust the things you're clicking on.
If you have to visit websites or try programs you don't trust, some people have virtual machines specifically for those situations. They'll visit the site/open the program inside the VM, and if something sketchy does happen, it'll be contained within the VM and not infect the host OS (unless it's incredibly sophisticated malware that can break out of VMs--but very unlikely you'd be targeted by something like that).
If you're really paranoid, you can save the state of the virtual machine before use, and restore the prior state every time you use, it, preventing any changes to the VM. You would occasionally want to start it up, install all the recommended updates, and then save the state again though.
1. Antivirus software that gives a false sense of security being popular.
2. The vendor refusing to fix vulnerabilities that give attackers complete control because of backward compatibility concerns:
http://foxglovesecurity.com/2016/01/16/hot-potato/
3. UAC prompts that annoy users to the point where the user either turns them off or automatically clicks yes. This is in part because of the even weirder situation of legitimate software often being written to touch things that it has no business touching.
4. End users trained to execute software obtained from random internet sites.
5. File names used to identify files as executable.
There are probably other backward things with regard to security too, although I cannot think of them offhand.
Your best choices would be installing a Linux distribution or buying an Apple machine running Mac OS X. If you must use some sort of Windows, check out ReactOS:
That likely does something by virtue of not having same bugs and not having yet implemented the legacy things that exploits often target. It is not as good for security as Linux or Mac OS X though.
It's impossible to determine whether software is malicious or not (Rice's theorem).
Antivirus software only reliably detects code that is identical to known malicious software.
Which is why proof-carrying code [https://en.wikipedia.org/wiki/Proof-carrying_code] is a good idea: the onus ought to be on the programmer to provide (machine-checkable) evidence that their program is safe to use, for whatever notion of “safe” might make sense in your system.
Better route was started in Burrough's where you pick a language good at correct programs and carefully design a safe machine around it. Same with System/38, SAFE (crash-safe.org) for functional, and Cambrige's CHERI for C language. The fundamentals work as advertised along with ability to enforce arbitrary security policies. Then design and security stuff are built on that. Only thing known to work consistently to any degree of success.
On COTS hardware, separation kernels and compiler transforms on legacy code are about best that we can do.
The only reliable things in security are the things that an attacker cannot bypass even when knowing that they in use (e.g. RSA). The premise of the article being discussed is that heuristics are trivial to bypass.
It looks like "halting problem being unsolvable" -> "rice's theorem" by a subset relationship. Consequently, if rice's theorem were false, you could solve the halting problem by modus tollens.
That being said, I had using the halting problem as my way of saying that identification of malicious software is impossible because infinite loops can be malicious and I had been unaware of rice's theorem. I will use that in my explanations in the future.
The only thing that antivirus software does semi-decently is identify known software binaries. Antivirus software cannot reliably identify unknown binaries through heuristics because writing software to understand unknown software binaries is impossible in general. There are potentially an infinite number of ways of proving that, but the easiest way that occurs to me is that one of the many things necessary for understanding unknown software in general is solving the halting problem, which was proven to be impossible in general by Alan Turing.
Furthermore, the utility for a database of known malicious binaries is practically non-existent. Malicious software is always designed to exploit some vulnerability and once the vulnerability is fixed by the vendor, there is nothing for the antivirus software to do. If you could apply the definition update that the antivirus software needed to catch malicious software, you could have applied the vendor patch that fixed the vulnerability the malicious software used in the first place. That not only makes the definition update unnecessary, but handles the unknown things that the definition update would never have caught.
In the cases of a vendor being slow to patch, refusing to patch (e.g. the exploits used by the hot potato proof of concept code for all current Windows versions) or the user not applying the patch in time (e.g. lack of scheduled downtime), the inability of antivirus software to catch unknown software using those vulnerabilities provides a false sense of security. If a system is specifically targeted by a malicious hacker, the hacker would use something that antivirus software would not catch, such as a script kiddie tool against which there are no known definitions or custom code. Being unfortunate enough to be attacked by a virus, trojan, etcetera before they get definitions also means there is no protection.
Real security requires doing things like minimizing attack area and configuring things competently (e.g. not using your username as your password). That is something that you cannot get from an antivirus vendor.