Article Surfing Archive

This is the second in a series of articles highlighting reasons why we need a new model for anti-virus and security solutions.

Reason #2: the Desktop Security Software Risks

The risks of placing software on the desktop are such that I will be breaking this article into two parts.

Fundamentally we think of having software on our desktops as a good thing. I love downloading or installing new packages and seeing what new creative things people do to the user interface or what they do to make certain aspects of my life easier or more fun.

But there are problems inherent with software that resides on the desktop, especially security software. Software">All developers will know what I mean. First and foremost, desktop software can be reverse engineered. What*s that mean? Have you ever inadvertently double-clicked on a file and had garbage show up or seen something that looks similar to this?

The old hex dump. Programmers will know it well. We actually spend a good deal of time trying to read this stuff. Basically, if there are programs that can (and do) turn instructions like the following

If UserBirthDate < *01/01/1960* then
IsReallyOld = *Yes
Else
IsReallyOld = *No*
End If

into something like the picture above, then the reverse is true: people have developed software that can take that gobbeldy-gook in the picture above and turn it somewhat into the if-statement I wrote out. The reversing software won*t know that I had an item called UserBirthDate, but it will know I was testing for a value of January 1, 1960 and it will be able to say that based on that value I set another item to Yes or No.

So now we install our fool-proof anti-virus software on our desktop (or our firewall for that matter). Well, so too can a virus author. And that virus author or hacker will also have gotten a copy of the latest reverse-engineering software from his local hacking site. He now goes upon his task of reverse-engineering the software and then trying to decipher the results. It*s not easy but it can be done. Unfortunately, vendors know this and understand this as an acceptable risk.

The problem here is that your security software is at risk. If your vendor codes an error, the virus author can and will detect it. For example, if your vendor should exclude a file from scanning, it*s possible the virus author will figure out which file (or type of file) that is and bury his code there. If the vendor excludes files from scanning or heuristics, it*s possible that virus author will figure out a way to corrupt that file.

That being said, there are other risks. As we have said, once software is on the desktop it affords virus authors an opportunity to reverse-engineer security software. The knowledge that reverse-engineering provides is invaluable to a virus author when building his next software attack. Third, virus authors can learn where the anti-virus vendors put there software and put the links to their software (directory folders, registry entries, etc.). This too is invaluable information. In fact, in some ways it teaches people intent on writing malicious software clues as to how to infiltrate the computers* operating system, where registry entries need to be made to force software to be loaded every time a computer is started, etc.

This information is generally available all over the web and in manuals for operating systems, especially manuals on such subjects as the Windows Registry. But having the software teach you where things belong to be effective is powerful knowledge.

Lastly, and perhaps most significantly, is the issue of forebearance. The anti-virus vendors usually know more about the potential exploits inherent in programs than virus authors but they are bound by the fact that should they try to prevent them before the exploits occur, they could be branded as irresponsible for teaching virus authors about these very exploits.

For example, when Microsoft first released the macro capabilities of Word, anti-virus vendors immediately realized the potential for danger in macros, but they were handcuffed. If they released software that disabled macros before the first macro virus was ever released, they would signal to virus authors the inherent destructive powers of macros. They chose instead to wait, handcuffed by the limitations of desktop software.

Until the Internet there really has been no better medium for delivering virus solutions than desktop software. It was relatively inexpensive to deploy (either market the software and sell it in stores or provide free downloads on bulletin boards and web sites). It is, however, expensive to keep updated in terms of time and effort, even with automated update systems.

The Internet caused several things to happen: by becoming a powerful medium for sharing files, whole families of viruses disappeared practically overnight (boot sector viruses, for example); by becoming the option of choice for sharing files, it was easier to infect a single file and have thousands download it.

A better solution is to place the security software in an offsite appliance of its own making. All Internet, intranet, networking connections flow through the appliance.

Selling off the shelf hardware appliances with built-in security software is better than a desktop software solution but it still suffers *to a lesser extent- from the pratfalls that desktop software falls prey to.

Even better is to create a service that a 3rd party vendor manages in a secure environment. In such an instance both the software and the hardware are away from the prying eyes of the malicious software authors. This further reduces the opportunity for malicious authors to discover the tricks and techniques employed by the security vendors to protect you.