27

Posting systems are vulnerable to virus and worms and having an antivirus is almost necessary. How is it possible that hardware antiviruses don't exist?

The idea sounds pretty good, if the antivirus resides on reprogrammable chips similar to the one that hosts the BIOS, then it would be immune to attacks yet still upgradeable. Also it would have higher privileges and that would solve the problem of being unable to repair in-use system files.

Is there something I am not thinking of that makes this impossible to implement?

|improve this question
  • 1
    I never thought of this, but you are right, in a way. You have one error in your question, though: the BIOS is firmware. The chip is not "reprogrammable". Rather, firmware, like the BIOS, which IS reprogrammable (because it is software), interfaces directly with the hardware. – trysis Nov 23 '14 at 21:37
  • 2
    "Also it would have higher privileges" - you'll need some magic for that... Current CPUs don't have an extra privilege level that is not yet used by OS... – Alexei Levenkov Nov 24 '14 at 5:23
  • 4
    Software antivirus sucks already bad enough, and there is zero advantage in having it "in hardware", only more disadvantages. Avast Internet Security just updated itself an hour ago and by the way made my computer unusable (iSCSI no longer working). Luckily restoring to the previous system save point worked. I wouldn't want to have that kind of crap in the BIOS where you can't just click on "Restore Windows". – Damon Nov 24 '14 at 12:19
  • 4
    The thing that makes computers so useful is that they are inherently instructable. We can program them to do a truly staggering number of things. Of course, the downside of that is that other people can program them to do things we don't want them to do too, and it's not like there's an easy way, or any universal way to decide which programs are bad, and which aren't. I mean, spyware's bad, right? Oh, except it's also used by employers to keep an eye on their employees, and parents to watch their kids online. Anything you do to make computers less programmable makes them less useful. – HopelessN00b Nov 24 '14 at 13:40
  • 1
    The problem with the antivirus and antimalware it's not that it's software. It's that there are 0 day exploits that are very hard to detect/stop and unknown exploits. Even when solutions do come along to figure out ways to stop some 0 days attacks there is always something else lurking in the shadows. Look at Regin (recently disclosed by Symantec), very complex, very hard to detect. If the hardware can bring something extra to the table that the software was not able to do sure thing, let's use it. If not, that's just a waste of time. – sir_k Nov 24 '14 at 14:35
24

If the chip is writable from within the OS, the malware can write to it too, so it wouldn't help there.

Also, anti-malware software has to handle threats that are only a few hours old. Having to reboot your computer to upgrade the anti-malware software that's running on its own hardware would suck, so we need to be able to upgrade it from within the OS. If we can write to the chip from the OS, so can the malware.

In order to make a secure hardware anti-malware you first have to change the main task of the program. Anti-malware software basically have a list of malicious software. If a program is in that list, it's blocked and removed. If not, we let it run. Every time a new piece of malware is written we have to add it to the list. Thus, the software can only be reactive, with the need to update the (huge) list all the time. If, on the other hand you have a list of programs that are allowed to run and block everything else you don't need to update that list all the time; only when you want to run a new program. Any malware, unknown or well known, would be blocked by this implicit deny. For many sensitive environments you don't install new code every day. ATM's need to run one piece of software. Nothing else. The list basically wouldn't change.

The problem is that there is no generally feasible list of OK programs. You'd either have to have a relatively small list of the programs you need to be able to run on your computer, which has to be made specifically for you, or you'd have to have an enormous list of any programs that anyone would ever want to run.

To generate that list, the easiest would be to add every possible program, and remove all the bad ones, which is equivalent to what anti-malware software does today, rather that the implicit deny. You simply cannot get a list of all non-malicious programs that will ever be written without including ones that won't be.

It could work, if you do it right. But it's generally not feasible. Also, it would really be a terrible thing to change to implicit deny for anti-malware companies trying to sell subscription services.

As for the extra privilege level; sometimes you have to escalate privilege, and if you can, malware will. And the inability to edit system files, you just added another layer. The top layer will still have that problem.

|improve this answer
  • 1
    Or you implement Hardware-Level Checking of Signatures in executables and let only signed code run! The upside is you only need a few ROOT-CA-Certificate in your hardware, which is only changed every few years and most professional business software is signed, with a valid chain you are pretty safe - and more important, you know who to sue if malware is executed, because someone has signed it – Falco Nov 24 '14 at 20:56
  • 5
    @Falco That's still an unacceptable solution for consumer machines that need to compile code. And, of course, if you start inspecting uncompiled code for malware, I'd like to hear your solution to the halting problem. – Riking Nov 25 '14 at 1:56
  • @Riking You could adopt the Nintendo/PlayStation/Xbox/iOS "only professional developers need to compile code, not consumers" model and have the OS publisher certify all code that runs on machines without a paid-up developer certificate. – Damian Yerrick Nov 25 '14 at 4:13
  • 6
    @tepples: Good luck doing that with a PC, though. You already see people intentionally breaking the security of their iPhones, because security and restrictions are basically one and the same. – cHao Nov 25 '14 at 5:12
  • 1
    @tepples: As soon as the system runs any kind of software that provides a macro definition interface of sorts, that model sounds more like a general headline than an actual thing that you can specifically rely on for anything. The concept can be held upright to some extent with Nintendo/PlayStation/Xbox because games often do not need to provide the flexibility and versatility that is expected by office-level applications on general purposes computers. – O. R. Mapper Nov 25 '14 at 11:43
13

There is no difficulty in BIOS based malware/viruses, they already exist, as does "memory only" malware. Had I to guess why it isn't more prevalent than normal viruses/malware, I would say that this is because BIOS software is vastly different than a normal operating system. There is a cost associated with creating malicious software, and the authors are likely targeting software where they can get the most bang for their buck.

Let's pretend to be software developers for a moment. We design our software to be compatible with as many devices across the board. Here are our choices with a generic value for the amounts of users we'd like to see run our software:

Windows Users - 10
OSX Users - 4
Linux Users - 4
Others - 1

Where does BIOS fit into the equation here? Let's take a few samples of BIOS manufacturers

Phoenix
Asus
ACER
AOPEN
Dell
Fujitsu
Gateway
IBM
Intel

And that list grows and grows. As a software developer, why would I want to focus on creating something that targeted when I'd have no initial idea of what BIOS software my client would be running. It is not cost effective. Now, let's replace the above instance with a "malicious software developer." What incentive would they have to focus on say 30+ BIOS manufacturers, versus say: 2 operating systems which are heavily used.

There has never been a time where it has been difficult to create BIOS based "on chip" like viruses. It is not cost effective. Most malicious software developers create their executables to scale, it just makes sense. Normally, when I have analyzed BIOS/boot based things, it has appeared to have been a highly targeted attack. Developing these types of exploits take time, a lot of recon to ensure you're sending the right exploit to the right target (you wouldn't waste time creating ASUS based malware, only to discover your target is using Intel based BIOS firmware.)

Malicious authors on say the state level vary differently from cybercrime groups. Some of these guys (state actors) disappear in certain countries. Why chance spending so much time, effort, and money to target the BIOS software when you could focus on the operating system, then move to memory.

|improve this answer
  • 8
    -1) this is a great answer, but it does not answer the question of "Why no hardware ANTIvirus?" – Lyndon White Nov 23 '14 at 23:44
9

Modern OSes already have privilege isolation, and modern antivirus programs already use that mechanism to try to avoid interference from lesser privileged malware.

There's no reason in principle that you can't introduce yet some higher privilege level (which seems to be the thrust of your question)--many people use virtual machines to do exactly this. (There's no reason for this to be "hardware antivirus," however.)

Any interface between the lower privilege and higher privilege execution contexts is, of course, a possibility for privilege elevation vulnerabilities, which occur both in the OS itself and, with somewhat greater rarity, across virtualization boundaries (e.g. http://threatpost.com/virtual-machine-escape-exploit-targets-xen-090612/76979, http://www.kb.cert.org/vuls/id/MAPG-8TVPQL), so this isn't a panacea.

But in reality, the problems with antivirus are deeper and more fundamental than the issue of privilege isolation. Antivirus engines are of questionable value (given the heuristic nature of their detection) and are often themselves a source of vulnerabilities--building a big bag of file parsers that try to parse every file on disk (often with elevated privileges!) is just a recipe for disaster (e.g. http://www.blackhat.com/presentations/bh-europe-08/Feng-Xue/Whitepaper/bh-eu-08-xue-WP.pdf, http://mincore.c9x.org/breaking_av_software.pdf).

|improve this answer
6

Secure boot

What makes you think its doesn't exist? Its pretty basic in principle, due to lack of memory in UEFI and limited scope for patching vulnerabilities, instead of detecting malicious code, it instead verifies your boot image with a signature. However, the main issue with secure boot is that not everyone can sign a boot image with an authorized signature (by design).

This means that for people who compile their own OSes, they won't be able to run their own OS. Additionally, if the user were able to sign their own OS, a virus could conceivably sign itself when installing itself.

|improve this answer
  • It would be possible to design a system with a hardware- unalterable startup ROM that would validate a boot image against a public key which was stored in a removable device would could not be written without physical tampering, and which would allow one to to make any such tampering evident. I don't know that the number of people wanting to write their own OS is sufficient to justify such a thing from a marketing perspective, but it shouldn't be difficult. – supercat Nov 24 '14 at 20:52
  • @supercat No...the issue is that the user would have to have access to a private key to sign his boot loader. But if the user has read access, so would any exploit. Thus you would want to sign your boot loader on a clean room machine, but where do you get the source to your OS? – Aron Nov 25 '14 at 6:37
  • All work on the boot image would need to be done on a clean-room machine to which the boot-image source code had been delivered via malware-proof means (e.g. by using an embedded-system SD-card interface that was connected via serial port to code which would do nothing but exchange data without interpreting the contents). Note that no outside code would ever be run on the clean-room machine; it would merely generate content to be run elsewhere. Even if the controller on the SD-card interface itself got infected, it would never have any access to the private key, nor any way... – supercat Nov 25 '14 at 17:31
  • ...of feeding the clean room machine any sort of code which the clean-room machine would ever be called upon to execute. – supercat Nov 25 '14 at 17:32
  • @supercat my sticking point is the "malware-proof means". Not to mention how do you ensure the integrity of the source you import? At some point there needs to be trust... – Aron Nov 25 '14 at 17:34
6

Besides what has been already said, I think there's a more fundamental problem: the hardware level is already too low to understand what's going on.

There have been hardware protections for low-level stuff (e.g. editing the boot sector), but let's take some common current-day malware/PUPs actions:

  • changing the user home page/settings to questionable sites;
  • adding programs that run automatically and try to scam the user in paying money;
  • recording keypresses to steal passwords;
  • sending spam/making web requests finalized to DDoS;
  • encrypting files and asking for ransom;
  • connecting to any possible network share to infect executables/Office documents;
  • asking a botnet-master for commands and executing them.

All this stuff is too high level for a hardware hook; when it comes down to hardware, all the high level logic (system calls, files/registry keys, DNS queries, HTTP connections, ...) is already gone, it's all "write on the disk at this location", "move those bytes in memory", "send these ethernet packets" and the like, so recognizing high-level dangerous patterns is way more complicated.

|improve this answer
3

The main problem with antivirus software is not really that it's vulnerable to attacks or lacks sufficient privileges. The problem is rather more fundamental, and it applies to all general purpose computers (universal Turing machines): in most cases, given a piece of code, the only way of telling what it will do is to run it. Moreover, code usually depends on input, and knowing what it does on most of its inputs is not a guarantee of what it will do on the rest. This is partly why writing bug-free code is so difficult, but it also means that the word processor you just installed might work fine for months, and then one day decide to wipe out your hard drive because you happened to type some letter one too many times -- and the only way to know that this will happen might be to try all possible input sequences.

If it's hard to believe that the purpose of a code could be hard to understand, see some examples of obfuscation. I'm a good C programmer, but understanding Ian Phillipps' entry would take me at least half an hour of intense concentration -- and this is C code; imagine if it was assembly. Now imagine trying to go through software the size of Microsoft Word trying to understand what it does in enough detail to make sure it won't hurt the computer. It's about as close to literally impossible as it gets.

Because of this fundamental issue, the only thing that antivirus software can do is keep a list of virus "signatures" and try to find them in the programs you install. Since new viruses appear daily, that's obviously a difficult thing to do and it requires constant updates. Doing it in hardware would make it no easier. An interesting alternative might be to restrict the amount of stuff programs are allowed to do. This is done to some extent -- modern OSes already disallow programs from modifying themselves, for example, and there are always boundaries to what each program can do. These boundaries can, however, always be sidestepped (often by tricking the user, or by exploiting some bug), and that will probably always be the case: too many constraints would render your computer useless.

|improve this answer
  • 1
    One could have a virus-proof system if one were willing to sufficiently constrain the actions the system could perform. What's difficult is defining a set of allowable operations which is too small to allow for the existence of a virus, but is still large enough to be useful. A web browser, for example, could easily be made malware-proof by ignoring all but the most basic of HTML tags and not providing any means of running any outside code. Many people would like more sophisticated browsers, but in some cases a restricted guaranteed-malware-free browser may be useful. – supercat Nov 24 '14 at 20:57
1

Hardware (firmware) virus detection techniques are possible, but would need to be different for every piece of hardware and every firmware variation. For example, as discussed above, the BIOS code is written by different manufacturers (PHOENIX, Dell, etc), and each would need its own antivirus detection routines. Since firmware doesn't change often, it would be simplest to implement a checksum technique to determine if any changes were made, instead of keeping abreast of every new variant of every new virus that could possibly exist.

|improve this answer
1

Malware that infects BIOS or HDD controller already exists. So your HW antivirus would either be un-updateable (and go obsolete before even getting shipped to consumers) or be updateable, and suffer similar infections your OS is having right now.

It's would be just another computer under the hood of your current computer. With all your current problems - just on two levels.

|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.