heuristics problem (was: Re: Malware "best practices")

[Ben Scott]

On 7/24/06, bmcculley at rcn.com <bmcculley at rcn.com> wrote:
>>  These articles seem like total crap to me.
>
> Ben, take another sip of java and lighten up...  :-)

  I call them as I see them.

  Besides, maybe you should lighten up and not take my grumbling so
seriously... ;-)

> So the rate of virus releases could be a good proxy for
> measuring the quality of the installed code base

  Hrrrm.  A good deal of what the pop press calles "viruses" is really
malware in the broader sense, and a good deal of *that* is really
user-distributed email worms, not viruses in the strict sense.  These
worms depend mainly on lusers running attached programs, not software
bugs.  Likewise adware/spyware/etc is frequently "deliberately
installed" by lusers.  So I'm not sure how valid even that speculation
is.

> More interestingly, heuristics would seem to have some
> inherent basic limitations.

  A'yup.

> 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)

  For the general case, I don't think you can.  It's possible to look
for specific behaviors that are "suspicious" and trap them.  For
example, it's unusual to write to the MBR, so many AV programs look
for that.  But it quickly turns into an arms race, and there's a lot
more ways to abuse a system then it is practical to look for.

  And then there's the classic quote, "Unix was not designed to stop
its users from doing stupid things, as that would also stop them from
doing clever things."  Same principle applies here.

> Virtual machine with heuristics in the vm host not in the virtualized client.

  Indeed.  I'm told this is the way many IBM mainframe OSes handle
security.  Don't bother trying to make a secure OS; implement a secure
VM, give each subject their own VM, and let them trash it as they
like.

  There's also the concept of not having (or not using) an
all-powerful superuser account.  It's been done before on other
(non-mainstream) OSes.  It is a somewhat foreign idea to *nix, but it
can be done, or so I'm told.  The SELinux subsystem, for example, can
be used to assign roles to different accounts, and restrict what those
accounts can do, at a fairly granular level.  The recent Nashua
meeting on that topic was very interesting in this regard, although it
was focused more on restricting specific service processes, not "root"
in general.  I suspect this is really the Right Thing, but is
non-trivial given the assumptions most people make about *nix.

  And sooner or later, you eventually will eventually reach a
superuser level.  For SELinux, someone has to be able to install
kernel upgrades, and if one can do that, one can subvert the system.
Even schemes that incorporate a hardware element (e.g., the "Trusted
Platform Module") have a superuser level -- it's just not a role you
hold, but a role held by whoever controls the hardware.  Then the
issue becomes, "Who will watch the watchmen?"

  Security is hard.

-- Ben