heuristics problem (was: Re: Malware "best
practices")
bmcculley at rcn.com
bmcculley at rcn.com
Mon Jul 24 00:29:01 EDT 2006
---- Original message ----
>Date: Sun, 23 Jul 2006 21:41:03 -0400
>From: "Ben Scott" <dragonhawk at gmail.com>
>Subject: Re: Malware "best practices"
>To: gnhlug-discuss at mail.gnhlug.org
>
> These articles seem like total crap to me.
>
> Despite all the talk about heuristics, virus detection is
>still almost entirely dependent on recognizing signatures of
>know viruses.
[...]
> Why are you posting this crap, Bill? You're better than that.
>
>-- Ben
Ben, take another sip of java and lighten up... :-)
Bill made a good point about virus testers being able to
define escaping detection by currently released AV products as
a minimum ship criterion. Doesn't matter if it's heuristics
or signatures, if the testers establish it's a miss before
they release it will be a miss. So the rate of virus releases
could be a good proxy for measuring the quality of the
installed code base - not necessarily the currently released
code base btw, but the unpatched legacy of past flawed
releases (viruses are just bad software karma).
More interestingly, heuristics would seem to have some
inherent basic limitations. How do you tell when code
executing with root privs is malware? (NOT a rhetorical
question btw, I'd seriously like to know if it is possible,
and how)
Point is that if malware code is running as root, all the
heuristics in the world will be blind to it. Heuristics
watching for writes to the hw boot block? NP. Just fly under
the radar by punching the right device registers, bypassing
the system drivers and any watchful AV heuristics...
Ok, maybe there is a way around this dilemna. Virtual machine
with heuristics in the vm host not in the virtualized client.
This is the flip side of the security puzzle about how to
prove the environment can be trusted, if it could be virtual
instead of physical? Makes key management, reverse
engineering protection, and a lot of other stuff very
problematic. But the AV potential could be the silver lining...
Back to that serious question, how could code running with
unauthorized privs be identified?
-bruce mcculley
More information about the gnhlug-discuss
mailing list