Re: Death of antivirus software imminent

On Dec 29, 2007, at 6:37 PM, Anne & Lynn Wheeler wrote:
> Virtualization still hot, death of antivirus software
imminent

My favorite virtual machine use is for the virus to install
itself
as a virtual machine, and run the OS in the virtual machine.
 This
technique should be really good for hiding from virus
scanners.

Cheers - Bill

------------------------------------------------------------
-----------
Bill Frantz        | I like the farmers' market   |
Periwinkle
(408)356-8506      | because I can get fruits and | 16345
Englewood Ave
www.pwpconsult.com | vegetables without stickers. | Los
Gatos, CA 95032

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

Bill Frantz wrote:
 > My favorite virtual machine use is for the virus to
install itself
 > as a virtual machine, and run the OS in the virtual
machine.  This
 > technique should be really good for hiding from virus
scanners.

re:
http://www.
garlic.com/~lynn/aadsm28.htm#2 Death of antivirus
software 
imminent
http://www.
garlic.com/~lynn/aadsm28.htm#4 Death of antivirus
software 
imminent

i commented on that in reference posts mentioning that there
have been
uses of virtual machines to study virus/trojans ... but
that
some of the new generation virus/trojans are now looking to
see if they
are running in virtual machine (studied?).

some of the current trade-off is whether that virtual
machine technology
can be used to partition off basically insecure operations
(which are widely
recognized as being easy to compromise) and then completely
discard
the environment and rebuild from scratch after every session
(sort of
the automated equivalent of having to manually wipe an
infected machine
and re-install from scratch).

the counter argument is that crooks can possibly also use
similar
technology to hide ... once they have infected the machine.
the current
issue is that a lot of the antivirus/scanning techniques are
becoming 
obsolete
w/o the attackers even leveraging virtual machine
technology.

The attackers can leverage the technology in an otherwise
poorly
defended machine. Some years ago there was a product
claiming
that it could operate even at a public access machine
because
of their completeness of their antivirus countermeasures ...
even
on an infected machine. I raised the issue that it would be
trivial
to defeat all such countermeasures using virtual machine
technology.
Somewhat of a skirmish resulted since they had never
considered
(or heard of) virtual machine technology ... for all i know
there
is still ongoing head-in-the-sand situation.

for little topic drift ... this blog entry:
https://financialcryptography.com/mt/archives/000991.ht
ml

and
http://www.
garlic.com/~lynn/aadsm28.htm#3
http://www.
garlic.com/~lynn/aadsm28.htm#5

there is some assertion that the crooks overwhelming the
defenders countermeasures because they are operating
significantly faster and more efficiently.

however, another interpretation is that the defenders
have chosen extremely poor position to defend ... and are
therefor at enormous disadvantage. it may be necessary
to change the paradigm (and/or find the high ground)
in order to successfully defend.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

There was a paper in IEEE Security & Privacy 2006 by Sam
King on how  
to do this kind of attack (his system was called SubVirt):
	h
ttp://www.eecs.umich.edu/virtual/papers/king06.pdf

However, in practice it turns out this is a much harder than
people  
think. See Tal Garfinkel's paper on precisely this topic at
HotOS 2007:
	http://www.stanford.edu/~talg/papers/HOTOS07/abstract.
html

-Angelos


On Jan 2, 2008, at 1:09 PM, Anne & Lynn Wheeler wrote:

> Bill Frantz wrote:
> > My favorite virtual machine use is for the virus
to install itself
> > as a virtual machine, and run the OS in the
virtual machine.  This
> > technique should be really good for hiding from
virus scanners.
>
> re:
> http://www.
garlic.com/~lynn/aadsm28.htm#2 Death of antivirus  
> software imminent
> http://www.
garlic.com/~lynn/aadsm28.htm#4 Death of antivirus  
> software imminent
>
> i commented on that in reference posts mentioning that
there have been
> uses of virtual machines to study virus/trojans ... but
that
> some of the new generation virus/trojans are now
looking to see if  
> they
> are running in virtual machine (studied?).
>
> some of the current trade-off is whether that virtual
machine  
> technology
> can be used to partition off basically insecure
operations (which  
> are widely
> recognized as being easy to compromise) and then
completely discard
> the environment and rebuild from scratch after every
session (sort of
> the automated equivalent of having to manually wipe an
infected  
> machine
> and re-install from scratch).
>
> the counter argument is that crooks can possibly also
use similar
> technology to hide ... once they have infected the
machine. the  
> current
> issue is that a lot of the antivirus/scanning
techniques are  
> becoming obsolete
> w/o the attackers even leveraging virtual machine
technology.
>
> The attackers can leverage the technology in an
otherwise poorly
> defended machine. Some years ago there was a product
claiming
> that it could operate even at a public access machine
because
> of their completeness of their antivirus
countermeasures ... even
> on an infected machine. I raised the issue that it
would be trivial
> to defeat all such countermeasures using virtual
machine technology.
> Somewhat of a skirmish resulted since they had never
considered
> (or heard of) virtual machine technology ... for all i
know there
> is still ongoing head-in-the-sand situation.
>
> for little topic drift ... this blog entry:
> https://financialcryptography.com/mt/archives/000991.ht
ml
>
> and
> http://www.
garlic.com/~lynn/aadsm28.htm#3
> http://www.
garlic.com/~lynn/aadsm28.htm#5
>
> there is some assertion that the crooks overwhelming
the
> defenders countermeasures because they are operating
> significantly faster and more efficiently.
>
> however, another interpretation is that the defenders
> have chosen extremely poor position to defend ... and
are
> therefor at enormous disadvantage. it may be necessary
> to change the paradigm (and/or find the high ground)
> in order to successfully defend.
>
>
------------------------------------------------------------
---------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

On Wed, 2 Jan 2008, Anne & Lynn Wheeler wrote:
> however, another interpretation is that the defenders
> have chosen extremely poor position to defend ... and
are
> therefor at enormous disadvantage. it may be necessary
> to change the paradigm (and/or find the high ground)
> in order to successfully defend.

Yes, I wish that were pointed out more often.  Detecting
viruses is a 
fundamentally losing battle: a sufficiently advanced virus
can fully simulate 
a clean computer for the scanner to run in.

On the other hand, writing an OS that doesn't get infected
in the first place 
is a fundamentally winning battle: OSes are insecure because
people make 
mistakes, not because they're fundamentally insecurable.

Detecting spam by analysis of the text is another losing
battle: even humans 
can't always agree on what's spam.

The maddening part is that security as an industry is almost
always forced to 
fight on the losing battlefields, even though we've had
beautiful, efficient, 
impregnable fortresses available for many years.  Any crypto
book from 20 
years ago can show you how to send an unforgeable email or
sign a binary, yet 
these notions still haven't widely caught on (and when they
have, as in the 
Xbox, they get hijacked for things like DRM and privacy
invasion).

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

Virtualization has become the magic pixie dust of the
decade.

When IBM originally developed VMM technology, security was
not a primary
goal.  People expected the OS to provide security, and at
the time it
was believed that OS's would be able to solve the security
problems.

As far as I know, the first real tie of VMM's to security
was in a DEC
project to build a VMM for the VAX that would be secure at
the Orange
Book A2 level.  The primary argument for this was:  Existing
OS's are
way too complex to verify (and in any case A2 required
verified design,
which is impossible to apply to an already-existing design).
 A VMM can
be small and simple enough to have a verified design, and
because it
runs "under" the OS and can mediate all access to
the hardware, it can
serve as a Reference Monitor.  The thing was actually built
and met its
requirements (actually, it far exceeded some, especially on
the
performance end), but died when DEC killed the VAX in favor
of the
Alpha.

Today's VMM's are hardly the same thing.  They are built for
perfor-
mance, power, and managability, not for security.  While
certainly
smaller than full-blown Windows, say, they are hardly tiny
any more.
Further, a major requirement of the VAX VMM was isolation: 
The
different VM's could communicate only through network
protocols.  No
shared devices, no shared file systems.  Not the kind of
thing that
would be practical for the typical uses of today's crop of
VM's.

The claim that VMM's provide high level security is trading
on the
reputation of work done (and published) years ago which has
little if
anything to do with the software actually being run.  Yes,
even as they
stand, today's VMM's probably do provide better security
than some -
many? - OS's.  Using a VM as resettable sandbox is a nice
idea, where
you can use it.  (Of course, that means when you close down
the sandbox,
you lose all your state.  Kind of hard to use when the whole
point of
running an application like, say, an editor is to produce
long-lived
state!  So you start making an exception here, an exception
there
... and pretty soon the sand is spilled all over the floor
and is in
your eyes.)

The distinction between a VMM and an OS is fuzzy anyway.  A
VMM gives
you the illusion that you have a whole machine for yourself.
 Go back
a read a description of a 1960's multi-user OS and you'll
see the
very same language used.  If you want to argue that a small
OS *can
be* made more secure than a huge OS, I'll agree.  But that's
a size
distinction, not a VMM/OS distinction....
							-- Jerry

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

One virtualization approach that I have not see mentioned on
this thread is
to run the virtual machine on a more secure OS than is used
by the
applications of interest.  

For example, one could run VMware on SELinux and use VMware
to host
Windows/Vista.  Thus, even if a virus subverts Windows it
still has no more
capabilities than any errant program in SELinux.  And, the
virus author has
to cope with the complications created by the dual operating
systems.

Me, I do just the opposite.  I browse the web with firefox
running on
SELinux (targeted policy) on VMware hosted on Windows XP. 

That would be secure if I didn't run as root half the time.

Chuck Jackson 

 




-----Original Message-----
From: owner-cryptographymetzdowd.com
[mailto:owner-cryptographymetzdowd.com] On Behalf Of
Leichter, Jerry
Sent: Wednesday, January 02, 2008 4:43 PM
To: Anne & Lynn Wheeler
Cc: Bill Frantz; Cryptography
Subject: Re: Death of antivirus software imminent

Virtualization has become the magic pixie dust of the
decade.

When IBM originally developed VMM technology, security was
not a primary
goal.  People expected the OS to provide security, and at
the time it
was believed that OS's would be able to solve the security
problems.

As far as I know, the first real tie of VMM's to security
was in a DEC
project to build a VMM for the VAX that would be secure at
the Orange
Book A2 level.  The primary argument for this was:  Existing
OS's are
way too complex to verify (and in any case A2 required
verified design,
which is impossible to apply to an already-existing design).
 A VMM can
be small and simple enough to have a verified design, and
because it
runs "under" the OS and can mediate all access to
the hardware, it can
serve as a Reference Monitor.  The thing was actually built
and met its
requirements (actually, it far exceeded some, especially on
the
performance end), but died when DEC killed the VAX in favor
of the
Alpha.

Today's VMM's are hardly the same thing.  They are built for
perfor-
mance, power, and managability, not for security.  While
certainly
smaller than full-blown Windows, say, they are hardly tiny
any more.
Further, a major requirement of the VAX VMM was isolation: 
The
different VM's could communicate only through network
protocols.  No
shared devices, no shared file systems.  Not the kind of
thing that
would be practical for the typical uses of today's crop of
VM's.

The claim that VMM's provide high level security is trading
on the
reputation of work done (and published) years ago which has
little if
anything to do with the software actually being run.  Yes,
even as they
stand, today's VMM's probably do provide better security
than some -
many? - OS's.  Using a VM as resettable sandbox is a nice
idea, where
you can use it.  (Of course, that means when you close down
the sandbox,
you lose all your state.  Kind of hard to use when the whole
point of
running an application like, say, an editor is to produce
long-lived
state!  So you start making an exception here, an exception
there
... and pretty soon the sand is spilled all over the floor
and is in
your eyes.)

The distinction between a VMM and an OS is fuzzy anyway.  A
VMM gives
you the illusion that you have a whole machine for yourself.
 Go back
a read a description of a 1960's multi-user OS and you'll
see the
very same language used.  If you want to argue that a small
OS *can
be* made more secure than a huge OS, I'll agree.  But that's
a size
distinction, not a VMM/OS distinction....
							-- Jerry

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

| One virtualization approach that I have not see mentioned
on this
| thread is to run the virtual machine on a more secure OS
than is used
| by the applications of interest.
| 
| For example, one could run VMware on SELinux and use
VMware to host
| Windows/Vista.  Thus, even if a virus subverts Windows it
still has no
| more capabilities than any errant program in SELinux. 
And, the virus
| author has to cope with the complications created by the
dual
| operating systems.
It's not clear to me what threats this protects you against.
 A Windows
virus would work within the Windows environment just as it
always did.
If that's *your* working environment, it's just as
contaminated as if
you were running Windows on bare metal.

Of course, if you're using the sandbox idea, you can throw
out your
contaminated Windows environment periodically and start from
fresh.
As always, you need to be in a position to throw
*everything* out,
which can be rather painful.

A virus that could break through Windows, then through
VMWare (with
or without SELinux), then actually do something in that
environment
to establish itself more strongly, probably doesn't exist
today - and
would be quite an interesting challenge.

| Me, I do just the opposite.  I browse the web with firefox
running on
| SELinux (targeted policy) on VMware hosted on Windows XP.
That's a more reasonable approach.

| That would be secure if I didn't run as root half the
time.
:-(
							-- Jerry

| Chuck Jackson 

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com