Slashdot Mirror
New Antivirus Tests Show Rootkits Hard to Kill
ancientribe writes "Security suites and online Web scanners detect only a little more than half of all rootkits, according to new tests conducted by independent test organization AV-Test.org. Many of today's products struggle to clean up the ones they find. AV-Test.org also found that a few big name AV scanners had serious problems finding and removing active rootkits, such as Microsoft Windows Live OneCare 1.6.2111.32 and McAfee VirusScan 2008 11.2.121."
Grass is green, sky is blue, Pope is Catholic, etc...
When people create these things... isn't the intent to make them hard to detect/kill?
What this article has highlighted, though, is that a thorough study on how those rootkits got installed in the first place (especially with regard to the level of user interaction required) combined with some basic education provided to end-users within the OS could go a long way. It's the whole ounce of prevention worth a pound of cure thing. Obviously the cure is not yet up to snuff... and potentially never will be.
Proudly supporting the Libertarian Party.
In other news: half of jokes made on Slashdot are incorrectly interpreted as serious commentary.
If you read TFA it says that some products were actually able to detect, though not remove, as many as 29 out of the 30 rootkits tested once they were installed.
That's far higher than I would have expected. I thought the whole idea of a rootkit is that it modifies/hooks the kernel to make detection from userspace practically impossible, so either they're using poor/outdated rootkits or the antivirus makers are actually doing a pretty good job of detecting them (gasp).
Personally I run virus scans from a clean windows PE disk on any windows machine I suspect to be infected anyway; partly because some malware is very good at hiding itself from the OS once it's installed, partly because it makes removal much easier, but I wouldn't read these results as being bad for (some of) the antivirus makers concerned, as the summary seems to suggest.
One of the things I hate about Microsoft software (indeed, almost all software thet runs in Windows) is non-descriptive file names. Back in the DOS days XR2732A.DLL might have made sense, but wouldn't "Run-time library of graphics functions for Word.DLL make a whole lot more sense? If in fact you had removed Word (or some game or whatever) you would know that you could delete the file with impunity.
mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
It would have to compare the checksum of every executable and every DLL on the system to known good examples to confirm they've not been infected (though to be honest I suspect most of them are just taking advantage of the labyrinthine mess that is Windows rather than going to all the hassle of infecting files).
It would have to confirm that every patch which has security implications has been installed (eg. there have been patches which deal with code which loads JPEGs - not much point in rebooting if the first thing that's going to happen is you get reinfected so that's got to be solved).
It would have to delete any application that isn't on a known-good list. So you need a "known-good" list covering every Windows application known to man, and you also need to account for those rare cases where you're dealing with a software developers machine and there are executables on there that aren't known to man.
And remember what I said earlier about "there have been vulnerabilities in code that reads JPEGs"? Well, that means you need to delete any JPEG which isn't known-good, And any other file for which similar vulnerabilities in decoding have been found. Or it's possible that the first thing that will happen on reboot is the user will email out this "kewl JPEG" to all their friends, forwarding the malicious payload in the process.
And you need to do all this without breaking anything in the process. Or else if you do, you might just as well have wiped and rebuilt the system.
Maybe, but spaces in file/directory names are an abomination :-). I'd be ok with something like:
Run-timeLibraryOfGraphicsFunctionsForWord.DLL