Technophobe wrote:
> PC Magazine - SubVirt, a proof-of-concept virtual machine
> rootkit created by MS Research and the University of Michigan,
> pushes the envelope for hiding malware. Will this new threat
> strike from below?
http://www.eecs.umich.edu/~pmchen/papers/king06.pdf
What this will mean is the increased use of boot-from-CD scanning
methods. This will require a new feature for AV software - easy to
use, seemless updating of a boot-from-CD-R image when desired by the
user. Either that, or (as I always advocate) scanning the drive as a
slave on a trusted and capable system.
Only Windows XP is mentioned here. Still waiting to hear about Win-98
root kits.
-------------
[43] S. Sparks and J. Butler. Shadow Walker: Raising The
Bar For Windows Rootkit Detection. Phrack, 11(63),
August 2005. (
http://www.phrack.org/show.php?p=63&a=8)
"even the most sophisticated Windows kernel rootkits, like FU, possess
an inherent flaw. They subvert essentially all of the operating
system's subsystems with one exception: memory management. Kernel
rootkits can control the execution path of kernel code, alter kernel
data, and fake system call return values, but they have not (yet)
demonstrated the capability to 'hook' or fake the contents of memory
seen by other running applications. In other words, public kernel
rootkits are sitting ducks for in memory signature scans. Only now
are security companies beginning to think of implementing memory
signature scans."
(I thought that many AV software performed memory scans - ?)
"Now imagine a rootkit that makes no effort to change its superficial
appearance, yet is capable of fundamentally altering a detectors view
of an arbitrary region of memory. When the detector attempts to read
any region of memory modified by the rootkit, it sees a 'normal',
unaltered view of memory. Only the rootkit sees the true, altered view
of memory. Such a rootkit is clearly capable of compromising all of
the primary detection methodologies to varying degrees. The
implications to misuse detection are obvious. A scanner attempts to
read the memory for the loaded rootkit driver looking for a code
signature and the rootkit simply returns a random, 'fake' view of
memory (i.e. which does not include its own code) to the scanner.
There are also implications for integrity validation approaches to
detection. In these cases, the rootkit returns the unaltered view of
memory to all processes other than itself. The integrity checker sees
the unaltered code, finds a matching CRC or hash, and (erroneously)
assumes that all is well. Finally, any anomaly detection methods
which rely upon identifying deviant structural characteristics will be
fooled since they will receive a 'normal' view of the code. An example
of this might be a scanner like VICE which attempts to heuristically
identify inline function hooks by the presence of a direct jump at the
beginning of the function body."
---------------