To view parent comment, click here.
To read all comments associated with this story, please click here.
It's not an adequate solution. If On-Access scanning could be made perfect (not the definitions but the scans need to be unavoidable) and only slowed things minorly (less than a 10% drop in performance) then it would be an adequate solution.
But On-Access scanning misses stuff, and it's probably more than 60% slower than just opening the file and reading it (on average).
I've seen 2GHz Pentium 4's appear slow compared to my 700 Celeron just because they ran McCafee (and probably had some spyware as well) and I didn't. I'm not exaggerating.
After-infections "solutions" are not solutions, they're ugly hacks. It may be better than nothing, but it still sucks.
"And acutally solve the problem with a 20 minute training session explaining to people how best to judge the trustworthyness of software they run."
It doesn't take 20 minutes to say to people "don't run closed-source applications".
There are of course some closed-source applications that are indeed trustworthy, but the real problem is that an end user has no way to tell which applications these are.
Even "from a reputable company" doesn't do it. reputable companies do not have the same interest as end users, and we see this in some cases as software such as the Sony rootkit and Windows Vista DRM produced by reputable companies but still effectively being malware from the end users point of view.
There is just one way for an end user to be assured of the trustworthiness of any program, and that is to ask these few simple questions:
(1) Is the source code available for inspection?
(2) Is the source code inspected by capable people other than those who wrote it?
(3) Do those same people who inspected the code then use that code themselves as end users?
Any application program for which the answers to the three questions above is "yes" is a trustworty application.
Hopefully by that time, if it comes, people will realize how terrible AV software is at handling the problem.
I'm in total agreement. Hardening Linux is a much better route. Making things like SELinux, SSP, and PIE not only usable by the masses but enabled by default on Linux distributions is a much saner approach. In addition smaller code, fast patching, and code auditing certainly help.
It's useless to attempt to try to keep up with virus writers by constantly updating virus signatures. Make the code secure in the first place! Hardened code will prevent all kinds of nasty things from many attack vectors, while a virus definition will only prevent one virus from one attack vector. Tomorrow there will be another attack vector and the need for another definition. There are thousands of viruses floating about that could be made useless by following secure coding practices. No need for AV scanners.
No software is perfect, and that includes AV programs. They create a single point of failure, which is unacceptable in terms of real security.
I was waiting for the v word to be mentioned.
There are thousands of viruses floating about that could be made useless by following secure coding practices. No need for AV scanners.
There are also thousands of viruses floating about that can't be stopped by secure coding practices. A simple 'botnet' style DDOS client can do everything it needs just using the same privileges that Apache2 needs to run, so any sort of injection attack (they exist) against any child process of Apache will be able to make the machine/server a zombie.
A single mistake in (for example) the SSH source (Unlikely I know but there are other packages with similar security needs) would make a system vulnerable.
99% of attacks on my servers come in the form of automated 'skriptkiddie' style scans. Most of these try to infect the target with malware that would be detectable by bog standard Antivirus software. So I refute your claim that there is 'No need for AV scanners'






Member since:
2005-11-27
Hopefully by the time that active real time file/virus scanning is needed we will have a much improved subsystem for it to run on.
Hopefully by that time, if it comes, people will realize how terrible AV software is at handling the problem.