Installation of Antivirus Scanners by Default

I am not happy with The Utility of Antivirus Tools (my edit years ago didn’t prevail and than forgot about it). Quote as now:

Antivirus products and personal firewalls [archive] are not drop in solutions for a secure host. Malware can often stay undetected and evade scans, while application level personal firewalls are often circumvented. [2] Polymorphic code [archive] and rootkits [archive] essentially render antivirus products helpless. [3] [4]

Antivirus tools are actually worse than useless. In the case of sophisticated and targeted attacks, the antivirus software can serve as a pathway to exploiting a system’s kernel, since they almost always run with administration level privileges. [5] Antivirus software also harms privacy by sending system files back to the company servers for analysis.[6] The software also actively conducts man-in-the-middle attacks on secure SSL connections, enabling very sensitive information to be viewed. [7]

“Antivirus tools are actually worse than useless.” - Really? It’s a good argument but empirically true too? Perhaps people who wouldn’t fall for popular methods of infection wouldn’t benefit from antivirus, actually suffer from increased attack surface. But for most users I guess antivirus might help and increased attack surface is theoretic.

ClamAV nowadays does have a background scanner / guard.

Related Debian ClamAV feature request:
add init script / systemd unit for clamonacc background scanner

I might be able to develop activating the background scanner by default, refuse execution of malicious files and graphically notify the user about it.

ClamAV nowadays developed by Cisco and might have made huge progress since I checked ages ago.

Also interesting:

We have LKRG, perhaps rootkit detection system - AIDE, then why not antivirus too? We’d be the first Open Source, public Linux distribution that installs Antivirus, rootkit scanner and kernel guard by default.

Yeah. In the cited article there was NSA exploits that got root by targeting the AV specifically (Kaspersky in that case) so not really theoretic, but something done in practice. Also the privacy problems make it a nonstarter.

AIDE is no more an “AV” than LKRG is. They focus on shutting down entire mechanisms of attack than try to compile a signature blacklist for every bad file in existence - which isn’t productive and is the first thing any blackhat tests their kit against before deploying. AIDE keep track of file hashes on the clean system and alerts you if something changed.

AIDE is an intrusion detection system that detects changes to files on the local system. It creates a database from the regular expression rules that it finds from the config file. Once this database is initialized it can be used to verify the integrity of the files. It has several message digest algorithms (md5, sha1, rmd160, tiger, haval, etc.) that are used to check the integrity of the file.

If ClamAV doesn’t report to a remote server, doesn’t have an unacceptable perf penalty and doesn’t run as root then it shouldn’t be that bad. If it does any of these it shouldn’t be considered.

2 Likes

It is definitely not theoretic. There’s stuff like Avast that had insecure javascript interpreters run with system privileges.

The methods used by antiviruses are terrible and I really don’t think we should embrace them. Antiviruses are even worse on Linux since there have been so little virus outbreaks that AVs’ databases are tiny. They’re essentially useless.

Software like ClamAV only serves to detect Windows viruses to prevent them from being infected when passing data to a Windows machine from Linux.

AV = Another Vulnerability

They aren’t the same at all. AVs are basically a blacklist of some software and attempts to enumerate badness. LKRG works by detecting any modifications to the kernel (well not all of the kernel, only parts that LKRG is designed to cover but you get the idea).

LKRG isn’t too effective either since it relies on the attacker not knowing about it but it’s at least effective against a lot of off-the-shelf malware.

1 Like

ClamAV is most used by mail servers to scan attachments before sending them to Windows clients.

Some vulnerabilities are non-exploitable if with full knowledge of LKRG. Links here:
LKRG Upstream Resources

Javascript with root seems bad design indeed. For ClamAV I haven’t heard about such design flaws yet.

I don’t know what quantifies little and how important numbers are. Linux malware does exist:

I don’t have a good list of questions which could help to resolve this. Here is a starter: How relevant it would these viruses in Whonix’s case have been and could AV have helped?

1 Like

That doesn’t make sense. If an exploit knows about LKRG, it can disable it entirely without too much effort in which case, LKRG won’t have any effect on later events.

1 Like

Please follow these LKRG Upstream Resources, specifically the video of the initial presentation where Adam mentions that some classes of vulnerabilities are rendered dysfunctional even with full knowledge of LKRG, full read/write primitive required. See also this old version of Whonix’s LKRG wiki page, comparison table. That version was deprecated since it wasn’t accurate enough and too many conditionals to simplify it that much.

2 Likes

https://www.rfxn.com/projects/linux-malware-detect/

1 Like

One thing that slightly worries me about antivirus software is virus definitions. If definitions are just static strings like file hashes, there probably isn’t a concern, but some applications might ship executable code, but there are much more complex forms of virus definitions which could in theory be complex enough that malicious rules could exist and exploit the antivirus engine. ClamAV for instance has the ability to execute arbitrary code as part of a detection routine:

  • ClamAV’s bytecode signature runtime, powered by either LLVM or our custom bytecode interpreter, allows the ClamAV signature writers to create and distribute very complex detection routines and remotely enhance the scanner’s functionality.

Of course, that bytecode interpreter could be sandboxed or similar, but still, this is scary for users who may suffer targeted attacks.

There’s also the problem of antiviruses processing arbitrary untrusted data to try to find malware inside it. ClamAV tries to dig into everything from Zip archives to InstallShield installers. This dramatically increases the system’s attack surface since now a vulnerability in any one of the 31 different extractors in ClamAV can result in a system compromise. (It also tries to decompress and de-obfuscate Windows EXEs in another 10 different ways, which makes things worse.) It’s the security vs. usability tradeoff again - the more tricks an antivirus uses to find malware, the better it can detect, but the more likely it is to be compromised itself.

Beyond that, because one can’t verify that the signatures actually do correspond to malicious code without being able to actually download the malware and study it themselves, one has to blindly trust that the antivirus vendor will not maliciously mark a safe program as malicious, and that the vendor actually knows what they’re doing and won’t do things that result in false positives. (Antivirus vendors are notoriously bad at the latter.)


With all of that said, an antivirus might be useful for scanning individual downloaded files when the user explicitly requests such scanning. That could be used to detect if a trusted source has been compromised, or to attempt to confirm a suspicion that an untrusted source is malicious. It wouldn’t be foolproof of course, but like many of our security measures, it would give a theoretical attacker a worse headache. To prevent the scanner itself from going rogue, it would need to be sandboxed in its entirety, preferably inside a virtual machine. Then the individual files to be scanned could be copied into the VM, scanned, and then the VM reset to its previous state before the scan. Maybe when/if vm-app-manager becomes a thing, we can introduce a file scanner. This could possibly be used for deep scans from a live ISO, depending on how much disk space it requires.

1 Like