Re: Death of antivirus software imminent

[Ray Dillinger]

On Fri, 2008-01-18 at 02:31 -0800, Alex Alten wrote:
> At 07:35 PM 1/18/2008 +1000, James A. Donald wrote:
> >
> >And all the criminals will of course obey the law.
> >
> >Why not just require them to set an evil flag on all
> >their packets?
> 
> These are trite responses.  Of course not.  My point is
> that if the criminals are lazy enough to use a standard
> security protocol then they can't expect us not to put
> something in place to decrypt that traffic at will if necessary.

I see your point, but I can't help feeling that it's a 
lot like requiring all houses to be designed and built with 
a backdoor that the police have a key to, in order to 
guarantee that the police can come in to investigate crimes. 

The problem is that the existence of that extra door, and 
the inability of people to control their own keys to lock 
it, makes crimes drastically easier to commit.  You think 
police don't use DMV records to harass ex-girlfriends or 
make life hard for people they don't like?  You think 
Private investigators and other randoms who somehow "finesse" 
access to that data all have the best interests of the public 
at heart?  You think the contractor who builds the house 
will somehow forget where the door is, or will turn over 
*all* copies of the keys? 

And stepping away from quasi-legit access used for illegitimate
purposes, you think there're no locksmiths whose services the 
outright criminals can't buy?  You think the existence of a 
backdoor won't inspire criminal efforts to get the key (by 
reading a binary dump if need be) and go through it?

> >I guarantee I can make any payload look like any other
> >payload.  If the only permitted communications are
> >prayers to Allah, I can encode key exchange in prayers
> >to Allah.

> Look, the criminals have to design their security system with
> severe disadvantages; they don't own the machines they
> attack/take over so they can't control its software/hardware
> contents easily, they can't screw around too much with the IP
> protocol headers or they lose communications with them, and
> they don't have physical access to the slave/owned machines.

That is a very petty class of criminal.  While the aggregate 
thefts (of computer power, bandwidth, etc) are impressive, 
they're stealing nothing that isn't a cheap commodity anyway 
and the threat to lives and real property that would justify 
the kind of backdoors we're talking about just isn't there. 
Being subject to botnets and their ilk is more like the 
additional cost of doing business in bad weather, than it 
is like being the victim of a planned and premeditated 
crime with a particular high-value target.  

Moreover, we know how to weatherproof our systems.  
Seriously.  We know where the vulnerabilities are and we 
know how to create systems that don't have them.  And we 
don't need to install backdoors or allocate law enforcement 
budget to do it.  More than half the servers on the Internet - 
the very most desirable machines for botnet operators, 
because they have huge storage and huge bandwidth - run 
some form of Unix, and yet, since 1981 and the Morris Worm, 
you've never heard of a botnet composed of Unix machines!  
Think about that!  They do business in the same bad weather 
as everyone else, but it costs them very little, because 
they have ROOFS!

I submit that the sole reason Botnet operation even exists 
is because so many people are continuing to use an operating 
system and software whose security is known to be inferior. 
A(nother) backdoor in that system won't help.

The criminals whose activities do justify the sort of backdoors 
you're talking about - the bombers, the kidnappers, the 
extortionists, even the kiddie porn producers and that ilk - 
won't be much affected by them, because they *do* take the 
effort to get hard crypto working in addition to standard 
protocols, they *do* own their own machines and get to pick 
and choose what software goes on them, and if they're 
technically bent they can roll their own protocols. 

Bear


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Allen]

Alex Alten wrote:

[snip]


These are trite responses.  Of course not.  My point is
that if the criminals are lazy enough to use a standard
security protocol then they can't expect us not to put
something in place to decrypt that traffic at will if necessary.


[snip]


Look, the criminals have to design their security system with
severe disadvantages; they don't own the machines they
attack/take over so they can't control its software/hardware
contents easily, they can't screw around too much with the IP
protocol headers or they lose communications with them, and
they don't have physical access to the slave/owned machines.

And, last I heard, they must obey Kerckhoff's law, despite
using prayers to Allah for key exchanges.

Given all this, I'm not saying its easy to do, but it should be
quite possible to crack open some or all of their encrypted
comms and/or trace back to the original source attack
machines.


However, we do know that "criminals" are not always lazy. The 
trite comment often said is that if they used the same level of 
effort in a legal enterprise they would have done quite well.


The other proof that they are not lazy is looking at the 
evolution of the sophistication of malware like Storm and 
Nugache. It takes some serious effort to overcome the real 
handicaps that you point out as well as the ratio of the power 
and numbers that are hunting to put them out of business to their 
own numbers.


In many ways it is similar to a guerrilla war where many of the 
advantages are actually held by the tiny band of insurgents, who, 
greatly outnumbered and out-gunned, can in fact change history. 
The Swiss know this and train their military based on this.


Do not be surprised if the dissidents of all stripes use 
improvisation based on malware and other tools like onion routing 
to further their causes and evade suppression.


BTW, while I do not think all dissidents are righteous or 
fighting for righteous causes this does negate the general idea. 
A hammer is a hammer. Good or evil is independent of the tools, 
it depends on what one is pounding, nails or heads.


Best,

Allen

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Jonathan Thornburg]

Alex Alten wrote:
> Generally any standard encrypted protocols will
> probably eventually have to support some sort of CALEA
> capability. For example, using a Verisign ICA
> certificate to do MITM of SSL, or possibly requiring
> Ebay to provide some sort of legal access to Skype
> private keys.

I can certainly imagine various countries legislating such backdoors,
and other countries quietly installing them (assuming they aren't
already there for Skype).  And that will certainly help in catching
some fraction of unsophisticated crooks.

But botnets-for-rent are currently making pretty substantial amounts
of money (eg for sending spam, or ddos attacks, or as phishing hosts),
and are increasingly using professionally written malware.
(http://www.cs.auckland.ac.nz/~pgut001/pubs/malware_biz.pdf)

Given the lure of this much "easy money", I think it's much more
likely that the cleverer bad guys will just wrap an un-backdoored ssh
or ssl or ipsec or  layer inside the backdoored one(s), giving them (continued)
full security.  For better or worse, I think the "bad buys can use
strong crypto" horse left the barn a long time ago.


In a more recent message, Alex Alten wrote:
> the criminals have to design their security system with
> severe disadvantages; they don't own the machines they
> attack/take over so they can't control its software/hardware
> contents easily

I don't see your point -- surely once a machine is "recruited" into
a botnet, the botnet herder can and does load any software s/he wants
onto the "new recruit".


> they can't screw around too much with the IP
> protocol headers or they lose communications with them, and
> they don't have physical access to the slave/owned machines.

In what way has this stopped (or even slowed) the Storm worm,
to name one notorious example?

-- 
-- Jonathan Thornburg (remove -animal to reply) <[EMAIL PROTECTED]>
   School of Mathematics, U of Southampton, England
   "Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
  -- quote by Freire / poster by Oxfam


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Alex Alten]

At 07:35 PM 1/18/2008 +1000, James A. Donald wrote:

Alex Alten wrote:
> Generally any standard encrypted protocols will
> probably eventually have to support some sort of CALEA
> capability. For example, using a Verisign ICA
> certificate to do MITM of SSL, or possibly requiring
> Ebay to provide some sort of legal access to Skype
> private keys.

And all the criminals will of course obey the law.

Why not just require them to set an evil flag on all
their packets?


These are trite responses.  Of course not.  My point is
that if the criminals are lazy enough to use a standard
security protocol then they can't expect us not to put
something in place to decrypt that traffic at will if necessary.


> If there is a 2nd layer of encryption then this would
> require initial key exchanges that may be vulnerable
> to interception or after-the-fact analysis of the
> decrypted SSL payloads.

I guarantee I can make any payload look like any other
payload.  If the only permitted communications are
prayers to Allah, I can encode key exchange in prayers
to Allah.


Yeah and you can only communicate with Allah with
that type of design.

Look, the criminals have to design their security system with
severe disadvantages; they don't own the machines they
attack/take over so they can't control its software/hardware
contents easily, they can't screw around too much with the IP
protocol headers or they lose communications with them, and
they don't have physical access to the slave/owned machines.

And, last I heard, they must obey Kerckhoff's law, despite
using prayers to Allah for key exchanges.

Given all this, I'm not saying its easy to do, but it should be
quite possible to crack open some or all of their encrypted
comms and/or trace back to the original source attack
machines.

- Alex

--

Alex Alten
[EMAIL PROTECTED]



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[James A. Donald]

Alex Alten wrote:
> Generally any standard encrypted protocols will
> probably eventually have to support some sort of CALEA
> capability. For example, using a Verisign ICA
> certificate to do MITM of SSL, or possibly requiring
> Ebay to provide some sort of legal access to Skype
> private keys.

And all the criminals will of course obey the law.

Why not just require them to set an evil flag on all
their packets?

> If there is a 2nd layer of encryption then this would
> require initial key exchanges that may be vulnerable
> to interception or after-the-fact analysis of the
> decrypted SSL payloads.

I guarantee I can make any payload look like any other
payload.  If the only permitted communications are
prayers to Allah, I can encode key exchange in prayers
to Allah.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[lists]

From: Alex Alten <[EMAIL PROTECTED]>

Writing in support of CALEA capability to assist prosecuting botnet
operators etc ...

> Generally any standard encrypted protocols will probably eventually have
> to support some sort of CALEA capability.

So you havn't heard that the UK has closed down the "National High-Tech Crime 
Unit"
and the current way to report computer crime is at your police station (good 
luck
with that).  And there's not much sign of anyone else doing much better.
Here's some recent news:
http://www.news.com/8301-10784_3-9848743-7.html

Leaving aside the points others have made about how you can't expect the
cooperation of the crooks you are supposedly aiming for what staggers me
is that after 9 years on this list you still think the government -
any government - is looking out for your interests.


Also why is this thread called "Death of antivirus"?  What examples can
anyone give me in corporate or mass-market IT of people stopping doing
something merely because it didn't work?

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Sandy Harris]

On Jan 12, 2008 9:32 AM, Alex Alten <[EMAIL PROTECTED]> wrote:

> Generally any standard encrypted protocols will probably eventually have
> to support some sort of CALEA capability. ...

That's a rather large and distinctly dangerous assumption. Here's the
IETF's official line on the question, the "abstract" section of RFC 2084:

   The Internet Engineering Task Force (IETF) has been asked to take a
   position on the inclusion into IETF standards-track documents of
   functionality designed to facilitate wiretapping.

   This memo explains what the IETF thinks the question means, why its
   answer is "no", and what that answer means.

http://www.faqs.org/rfcs/rfc2804.html

The whole question was extensively discussed on an IETF mailing
list set up for the purpose before that RFC was written:
http://www1.ietf.org/mail-archive/web/raven/current/index.html

The aptly named RFC 1984 is also relevant.

Among the more obvious problems are the fact that complexity
is bad for security, that the US government has some history
of abusing wiretaps, and that other governments who would
have access to any such technology are even less trustworthy.

-- 
Sandy Harris,
Nanjing, China

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Steven M. Bellovin]

On Fri, 11 Jan 2008 17:32:04 -0800
Alex Alten <[EMAIL PROTECTED]> wrote:


> 
> Generally any standard encrypted protocols will probably eventually
> have to support some sort of CALEA capability. For example, using a
> Verisign ICA certificate to do MITM of SSL, or possibly requiring
> Ebay to provide some sort of legal access to Skype private keys.  

...
> 
> >This train left the station a *long* time ago.
> 
> So it's not so clear that the train has even left the station.
> 
You've given a wish list but you haven't explained why you think it
will happen.  The US government walked away from the issue years ago,
when the Clipper chip effort failed.  Even post-9/11, the Bush
administration chose not to revisit the question.

The real issue, though, is technical rather than political will.  CALEA
is a mandate for service providers; key escrow is a requirement on the
targets of the surveillance.  The bad guys won't co-operate...

--Steve Bellovin, http://www.cs.columbia.edu/~smb

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Alex Alten]

Sorry for the long delay in responding, I was traveling out of
"radio range" this week.

At 06:23 PM 1/4/2008 -0500, Leichter, Jerry wrote:

| > | ...Also, I hate to say this, we may need to also require that all
| > | encrypted traffic allow inspection of their contents under proper
| > | authority (CALEA essentially)
| > Why not just require that the senders of malign packets set the Evil Bit
| > in their IP headers?
| >
| > How can you possibly require that encrypted traffic *generated by the
| > attackers* will allow itself to be inspected?
|
| You misunderstand me.  We can for the most part easily identify
| encrypted data, either it is using a standard like SSL or it is
| non-standard but can be identified by data payload characteristics
| (i.e. random bits).  If it is a standard (or even a defacto standard
| like Skype) we can require access under proper authority.  If it is
| not (or access under authority is refused), then just simply block or
| drop the packets, there's no need to inspect them.
Just because it *looks* like SSL doesn't mean that the key it leaks to
you is actually valid.  And if it *is* actually valid, it doesn't mean
that there isn't a second layer of encryption inside the SSL session.


Generally any standard encrypted protocols will probably eventually have
to support some sort of CALEA capability. For example, using a Verisign
ICA certificate to do MITM of SSL, or possibly requiring Ebay to provide
some sort of legal access to Skype private keys.  If there is a 2nd layer
of encryption then this would require initial key exchanges that may be
vulnerable to interception or after-the-fact analysis of the decrypted SSL
payloads.


Go back to my example:  How will you distinguish between random bits
and a compressed video stream?  Do you assume that every codec in the
world will be registered?  How about a big scientific dataset of
floating point values?  Or some huge, validly formatted, spreadsheet
of such values?


Well, in order to be useful, codecs need to be well known.  If unknown
then they probably follow well known algorithms and thus probably be
ameniable to dogged digital forensics.


And that doesn't even consider obvious countermeasures.  What happens
if you decrypt and see a bunch of ASCII values that follow the first
and second order statistics of English text?  Sure, encoding my
encrypted data like that costs me some overhead - but given the
speed of today's networks, who cares?


Sure, but then interoperability goes out the window, and I'm pretty sure
that most thieves and attackers are not going to rebuild complex protocol
stacks and textual parsers from scratch.  This is what software reuse is
all about. In the case of botnet control lines then this may be more likely
but it seems to me that once you identify the suspicious packet flows
(which you are of course looking for on the infected machine), that dedicated
forensics analysis can be done successfully.  These packets would probably
have some sort of anomolous signature compared to more normal packets
of the same nature.  Also, don't forget, at the very least L4 signature
information will never be encrypted, otherwise it would be unroutable. And
remember even if you can decrypt the botnet control lines (which still must
do key distribution/exchanges over the same comm links as the victim
computers so it should be possible to intecept them) you can certainly
block them with something like a Cisco guard.


This train left the station a *long* time ago.


So it's not so clear that the train has even left the station.

- Alex


--

Alex Alten
[EMAIL PROTECTED]



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Adam Shostack]

On Mon, Jan 07, 2008 at 10:35:00AM -0500, [EMAIL PROTECTED] wrote:
| 
| Jerry,
| 
| It is always possible that I misunderstand the McCabe
| score which may come from the fact that so many build
| environments compute it along with producing the binary,
| i.e., independent of human eyeballs.  If complexity
| scoring requires human eyeballs or the presence of the
| designer's flow charts, then will we ever get meaningful
| numbers (sans artificial intelilgence) for code we did
| not write ourselves?  [...yes, this parallels the many
| arguments about how can you trust crypto code you didn't
| write, either...]
| 
| If McCabe scoring is your area, do you agree with the
| rule that a McCabe score of <10 is essential -- an argument
| that I am quoting from some NASA spec I read a while ago
| and can dig up again if that turns out to be necessary.

I'd question the description of "essential."  I've seen code (not at
my current employer) that was very successful in the marketplace that
likely scored in the tens of thousands.  The code had been unrolled
for performance reasons, and those responsible knew the cost they were
paying.

Adam

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Leichter, Jerry]

| Jerry,
| 
| It is always possible that I misunderstand the McCabe
| score which may come from the fact that so many build
| environments compute it along with producing the binary,
| i.e., independent of human eyeballs.  If complexity
| scoring requires human eyeballs or the presence of the
| designer's flow charts, then will we ever get meaningful
| numbers (sans artificial intelilgence) for code we did
| not write ourselves?  [...yes, this parallels the many
| arguments about how can you trust crypto code you didn't
| write, either...]
| 
| If McCabe scoring is your area, do you agree with the
| rule that a McCabe score of <10 is essential -- an argument
| that I am quoting from some NASA spec I read a while ago
| and can dig up again if that turns out to be necessary.
It's not really my area, sorry.  I'm just looking at this from
a very general point of view.  The point of McCabe and similar
measures is to point you to areas likely to contain bugs, or
that are likely to be particularly costly to implement.  Since
it's *humans* who actually implement (and produced bugs), a
meaningful measure can't depend on things that human beings
don't see.  This kind of analysis can be very powerful.  Everyone
has heard of Galileo's experiment dropping balls of different
weights and proving they hit the ground at the same time - but how
many people are aware of his theoretical argument that this must
be the case?  It's very simple:  Suppose a 2lb ball drops faster
than a 1lb ball.  Take the 2lb ball and pull it into a dumbell
shape, with (almost) 1lb at each end, but the ends very close
together.  Presumably, it still drops at the speed of a 2lb
ball.  Now pull the halves apart a bit at a time, gradually
thining out the connecting segment.  Eventually, you have two
1lb ball connected by a thread.  Does that drop at the speed
of the individual 1lb balls, or at the speed of a 2lb ball?
Clearly, it has to be both - the 1lb and 2lb balls must drop
at the *same* speed!

I pretty sure the build environments that give you McCabe measures
automatically are pulling the information from the control
flow analysis in compiler front ends.  This is where basic
blocks and the edges connecting them are first extracted.
Computing McCabe is trivial at this point - and the structure
it is computed on will correspond pretty directly to what a
human being would have perceived.  As various optimizations
are applied, the structure will change - and there is no
reason to believe that the McCabe measure won't change along
the way, since preserving McCabe is hardly a goal of optimizing
transformations.

| Always ready for re-education, but wary of the best
| being the enemy of the good,
|
| --dan
-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[dan]

Jerry,

It is always possible that I misunderstand the McCabe
score which may come from the fact that so many build
environments compute it along with producing the binary,
i.e., independent of human eyeballs.  If complexity
scoring requires human eyeballs or the presence of the
designer's flow charts, then will we ever get meaningful
numbers (sans artificial intelilgence) for code we did
not write ourselves?  [...yes, this parallels the many
arguments about how can you trust crypto code you didn't
write, either...]

If McCabe scoring is your area, do you agree with the
rule that a McCabe score of <10 is essential -- an argument
that I am quoting from some NASA spec I read a while ago
and can dig up again if that turns out to be necessary.

Always ready for re-education, but wary of the best
being the enemy of the good,

--dan

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Leichter, Jerry]

| ...Taking as our metric the venerable McCabe score:
| 
|v(G) = e - n + 2
| 
| where e and n are the number of edges and nodes in the
| control flow graph, and where you are in trouble when
| v(G)>10 in a single module, the simplest patch adds two
| edges and one node, i.e., v'(G)=v(G)+1, and that minimum
| obtains only for patches with no conditional branches in
| the patch
While I agree with your general point, this particular argument
is a misuse of the McCabe score.  Replacing:

X
Y

with

X
goto L
Y
L':
...
L:  Y'
goto L'

*at the machine code level* should have absolutely no effect on the
complexity of the algorithm (beyond any delta between Y and Y').  If you
insist on computing your McCabe score from the generated code, and it
gives you a different answer, then the score you are deriving is
meaningless.

The whole point of measurements like McCabe is to measure the complexity
of the algorithm *as seen by a human being*.  Automated code transforma-
tions that no human being ever sees should not affect it.  Otherwise,
you're going to have to throw out all your optimizing compilers.  The
transformation above occurs not just in patching but in other contexts -
e.g., this might be adventageous, with Y and Y' semantically equivalent,
if Y contains a bunch of calls that can't be reached with short
call sequences when at their original location, but can be if they are
relocated to L.  Or there might be cache interference effects that are
avoided by relocating.

Roughly similar patterns are used in generating code for loops, where
the surface semantics might require two copies of a test (one at loop
entry, one at the bottom of the loop) but this transformation lets you
get by with a single copy.

As long as the algorithm developer's view is that control flows directly
from X to Y (and there are no incoming edges at Y), this is one node, no
matter how the compiler or patch generator decides to shake and bake it
into memory.
-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Ivan Krstić]

On Jan 5, 2008, at 3:47 AM, Alexander Klimov wrote:

It sounds like: we cannot make secure OS because it is too large --
let us don't bother to make a smaller secure OS, just add some more
software and hardware to an existent system and then it will be
secure. Sounds like a fairytale


I don't think this is really being said. In fact, I've been pretty  
concretely saying "here's an OS not designed from scratch, but with  
certain pieces modified, that's likely to be extremely resistant to  
viruses, malware and other pests", in regard to the OS being designed  
for the OLPC. We're still implementing large chunks of the security  
system, but my spec[0] has been public for a year, our security  
working group contains a number of people from this list, and no one  
so far has claimed that this design won't successfully resist most --  
though not all -- classes of attacks we've seen or can presently  
imagine seeing in the desktop security realm.




[0] http://wiki.laptop.org/go/OLPC_Bitfrost

--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[dan]

Alexander Klimov writes, in part:
-+---
 | It sounds like: we cannot make secure OS because it is too
 | large -- let us don't bother to make a smaller secure OS,
 | just add some more software and hardware to an existent
 | system and then it will be secure. Sounds like a fairytale :-)


As yet another variation on the theme "complexity is the
enemy of security," consider patches.  Patches tend to
add complexity to the code they patch, viz., it is the
rare patch indeed that simply elides some non-working
feature.

Taking as our metric the venerable McCabe score:

   v(G) = e - n + 2

where e and n are the number of edges and nodes in the
control flow graph, and where you are in trouble when
v(G)>10 in a single module, the simplest patch adds two
edges and one node, i.e., v'(G)=v(G)+1, and that minimum
obtains only for patches with no conditional branches in
the patch.

If someone wanted to have fun, it would be to examine
what fraction of patches are themselves re-patched at
a later date -- as in Fred Brooks' famous dictum in
_The Mythical Man Month_ where, in paraphrase, he said
that you should stop patching when the probability of
fixing a known problem is no longer substantially
greater than the probability of simultaneously creating
an unknown problem.

Yet security patches are a special case: no vendor can
obey Brooks' Law, and so they will inevitably over-run
the boundary condition where the known flaw the new
patch patches is no longer likely to be substantially
more probable than the inadvertent introduction of an
unknown flaw at the same time.  As such, I would guess
that the more often an application receives security
patches the less secure it is, at least at the limit.

--dan

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[James A. Donald]

Leichter, Jerry
> > Why not just require that the senders of malign
> > packets set the Evil Bit in their IP headers?
> >
> > How can you possibly require that encrypted traffic
> > *generated by the attackers* will allow itself to be
> > inspected?

Alex Alten wrote:
> You misunderstand me.  We can for the most part easily
> identify encrypted data, either it is using a standard
> like SSL or it is non-standard but can be identified
> by data payload characteristics (i.e. random bits).

Steganography will beat that.  If the government demands
non random bits, non random bits will be provided.

> If it is a standard (or even a defacto standard like
> Skype) we can require access under proper authority.
> If it is not (or access under authority is refused),
> then just simply block or drop the packets, there's no
> need to inspect them.

This means that only authorized, regulated, officially
registered data formats shall be permitted.  It will be
almost impossible, most likely completely impossible,
for *my* format to get registered even though it sends
data completely in the clear.  Skype will be
grandfathered in, but the next Skype will not be.

So I will do what the bad guys do - steganograph my
entirely innocuous application, which would not need
cryptography at all except to escape intrusive
regulation, forcing me to hide my actual data format
inside a registered and officially authorized data
format.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Alexander Klimov]

On Fri, 4 Jan 2008, Alex Alten wrote:
> I think that we will have to move toward encrypting more data at
> rest in some manner that is that is easy for the user to use (like
> ATM cash cards) yet difficult for a malicious piece of software on
> the user's machine to circumvent.  This will require that all PC's
> ship with a trusted hardware/firmware chip AKA a reference monitor
> on the motherboard that can safely handle any red keys.  This also
> means the PC needs a trusted path to the user like the pin pad in
> ATM machines.  Many laptops now ship with fingerprint scanners, so
> maybe these things are not such an onerous requirement on PC
> manufacturers anymore.  Also the reference monitor could be used to
> prevent viruses being able to completely taking over the user's
> machine (maybe at least to maintain some sort of host IDS
> capability).

It sounds like: we cannot make secure OS because it is too large --
let us don't bother to make a smaller secure OS, just add some more
software and hardware to an existent system and then it will be
secure. Sounds like a fairytale :-)

Data at rest encryption is good since it protects data on lost
laptops, but it does not work against malware (if power is off,
malware does not run as well), especially if the data is used in
decrypted form on the running system. Probably with data at rest
encryption you can protect rarely used sensitive data, but not the
data you use regularly (by the way, how you are going to make sure
that you remove all malware when you work with that sensitive data?).

Now consider trusted paths: adding an additional `secure' button is
easy (MS was able to add more keys to our keyboards), but how you make
sure that (1) there is a trusted path from computer to user and (2)
users understand how to use and actually use it? There are many ideas
how to achieve the former, but apparently the latter always fails.

Fingerprint readers are added not because this adds much security (it
is reported to be easy to fool them once an attacker has a sample of
the fingerprint, and you are very unlikely to keep your computer free
from your fingerprints), but because USERS LIKE THEM: finger scanning
is faster than entering the password and seems to be more secure. I
suspect that if you use some data at rest protection and lose your
laptop while it is not completely off, the fingerprint reader is
counterproductive.

Using embedded hardware to scan for viruses seems not very realistic:
you probably can use it to check parts of RAM that are not supposed to
be changed, but a lot of malware live outside of those areas.

> We need really good IDS tools that track down the control lines of
> the botnets, etc., back to their actual handlers.  This may mean
> that each carrier must archive large amounts of either netflow data
> or even raw packets (say for non-TCP traffic) so that detailed L7
> analysis can take place to track botnet control lines back to their
> handlers in after-the-fact investigations.

Malware already evolved to P2P communication and thus it is
almost impossible to find the real master by tracing local
connections between hosts.

> Also, I hate to say this, we may need to also require that all
> encrypted traffic allow inspection of their contents under proper
> authority (CALEA essentially).  If we can do this then we can put
> real policing pressure on these virus writers, essentially removing
> them from being able to attack us over the Internet.

That is you propose to create a law that all malware must have some
key escrow mechanism? Or you mean that police should be able to force
every user to decrypt data sent to/from their computer? Both are
hilarious, but the sad thing is that in some countries each of them
can become a real law.

-- 
Regards,
ASK

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Leichter, Jerry]

| > | ...Also, I hate to say this, we may need to also require that all
| > | encrypted traffic allow inspection of their contents under proper
| > | authority (CALEA essentially)
| > Why not just require that the senders of malign packets set the Evil Bit
| > in their IP headers?
| > 
| > How can you possibly require that encrypted traffic *generated by the
| > attackers* will allow itself to be inspected?
| 
| You misunderstand me.  We can for the most part easily identify
| encrypted data, either it is using a standard like SSL or it is
| non-standard but can be identified by data payload characteristics
| (i.e. random bits).  If it is a standard (or even a defacto standard
| like Skype) we can require access under proper authority.  If it is
| not (or access under authority is refused), then just simply block or
| drop the packets, there's no need to inspect them.
Just because it *looks* like SSL doesn't mean that the key it leaks to
you is actually valid.  And if it *is* actually valid, it doesn't mean
that there isn't a second layer of encryption inside the SSL session.

Go back to my example:  How will you distinguish between random bits
and a compressed video stream?  Do you assume that every codec in the
world will be registered?  How about a big scientific dataset of
floating point values?  Or some huge, validly formatted, spreadsheet
of such values?

And that doesn't even consider obvious countermeasures.  What happens
if you decrypt and see a bunch of ASCII values that follow the first
and second order statistics of English text?  Sure, encoding my
encrypted data like that costs me some overhead - but given the
speed of today's networks, who cares?

This train left the station a *long* time ago.
-- Jerry

| 
| - Alex
| 
| --
| 
| Alex Alten
| [EMAIL PROTECTED]
| 
| 
| 
| 
| 

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Alex Alten]

At 05:47 PM 1/4/2008 -0500, Leichter, Jerry wrote:

| ...Also, I hate to say this, we may need to also require that all
| encrypted traffic allow inspection of their contents under proper
| authority (CALEA essentially)
Why not just require that the senders of malign packets set the Evil Bit
in their IP headers?

How can you possibly require that encrypted traffic *generated by the
attackers* will allow itself to be inspected?


You misunderstand me.  We can for the most part easily identify encrypted
data, either it is using a standard like SSL or it is non-standard but can be
identified by data payload characteristics (i.e. random bits).  If it is a 
standard

(or even a defacto standard like Skype) we can require access under proper
authority.  If it is not (or access under authority is refused), then just 
simply

block or drop the packets, there's no need to inspect them.

- Alex

--

Alex Alten
[EMAIL PROTECTED]



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Leichter, Jerry]

| ...Also, I hate to say this, we may need to also require that all
| encrypted traffic allow inspection of their contents under proper
| authority (CALEA essentially)
Why not just require that the senders of malign packets set the Evil Bit
in their IP headers?

How can you possibly require that encrypted traffic *generated by the
attackers* will allow itself to be inspected?  The NSA tried to do
that by concealing information about effective cryptographic algorithms
while providing algorithms it controlled.  But that horse has long
left the barn.  Effective algorithms are widely known and readily
available processors are easily fast enough to implement them.

If you require lawful code to use inspectable crypto, every time you
successfully inspect a datastream, you'll find - surprise! - that it
contains nothing objectionable.  Meanwhile, the streams you can't
"open up" will continue to contain all the dirty stuff.  And, of
course, if you attempt to "open" a stream and what you see looks
like random bits - is it because someone has given you a bogus
key, or because it's a compressed video stream?
-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Alex Alten]

At 11:23 PM 1/3/2008 +, Steven M. Bellovin wrote:

On Thu, 03 Jan 2008 11:52:21 -0500
[EMAIL PROTECTED] wrote:

> The aspect of this that is directly relevant to this
> list is that while "we" have labored to make network
> comms safe in an unsafe transmission medium, the
> world has now reached the point where the odds favor
> the hypothesis that whomever you are talking to is
> themselves already 0wned, i.e., it does not matter if
> the comms are clean when the opponent already owns
> your counterparty.
>
Right -- remember Spaf's famous line about how using strong crypto on
the Internet is like using an armored car to carry money between
someone living in a cardboard shack and someone living on a park bench?

Crypto solves certain problems very well.  Against others, it's worse
than useless -- "worse", because it blocks out friendly IDSs as well as
hostile parties.


I agree with these statements.  I have a couple of comments
regarding crypto and IDS.  I think that we will have to move toward
encrypting more data at rest in some manner that is that is easy for
the user to use (like ATM cash cards) yet difficult for a malicious
piece of software on the user's machine to circumvent.  This will
require that all PC's ship with a trusted hardware/firmware chip
AKA a reference monitor on the motherboard that can safely handle
any red keys.  This also means the PC needs a trusted path to
the user like the pin pad in ATM machines.  Many laptops now
ship with fingerprint scanners, so maybe these things are not such
an onerous requirement on PC manufacturers anymore.  Also
the reference monitor could be used to prevent viruses being able
to completely taking over the user's machine (maybe at least
to maintain some sort of host IDS capability).

For IDS, I think we need to think of it in more the context of policing.
These virus writers are human beings, and I suspect for the most
part a very small fraction of the total Internet population.  We need to
have tools and international Interpol-like treaties in place that allow
police to track down and arrest these people (or deny them access
via an ISP or a carrier).  Many of the tier 1 carriers apparently are
refusing to share IDS information with one another.  This needs to
change.  We need really good IDS tools that track down the control
lines of the botnets, etc., back to their actual handlers.  This may
mean that each carrier must archive large amounts of either netflow
data or even raw packets (say for non-TCP traffic) so that detailed
L7 analysis can take place to track botnet control lines back to their
handlers in after-the-fact investigations.  Also, I hate to say this, we
may need to also require that all encrypted traffic allow inspection of
their contents under proper authority (CALEA essentially).  If we
can do this then we can put real policing pressure on these virus
writers, essentially removing them from being able to attack us
over the Internet.

- Alex

--

Alex Alten
[EMAIL PROTECTED]



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Dan Kaminsky]

> Crypto solves certain problems very well.  Against others, it's worse
> than useless -- "worse", because it blocks out friendly IDSs as well as
> hostile parties.
>
>   
Yawn.  IDS is dead, has been for a while now.  The bottom line discovery
has been that:

1) Anomaly detection doesn't work because anomalies are normal, and
2) Unless you're scrubbing up and down the application and network
stacks, you just have no idea what the host endpoint is parsing.

At the point where crypto shows up, it's already too late.

--Dan

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Leichter, Jerry]

| >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.
| 
| Actually VMMs do provide some security, but not in the way you think.
| Since malware researchers typically run malware they're analysing
| inside a VM, quite a bit of malware will silently exit (or at least
| not exercise the "mal" part of its name) if it detects that it's
| running inside a VM.  So you can inoculate yourself against at least
| some malware by running your OS inside a VM.
Ah, yes - the unexpected side-effect which happens to be positive.

If you read Garfinkle et al's paper on the detectability of VMM's -
and the low likelyhood of ever producing an undetectable VMM's - you
can see some similar things happening.  Some of the techniques are
fairly universal - e.g., those based on measuring TLB sizes, which
is likely to be usable on any machine that uses virtual memory.  But
many others are based on ugly botches in the x86 architecture (e.g.,
the user-mode instructions like SIDT which reveal privileged state)
or the absurd complexity and rough edges of many I/O devices.

For security in general, unexpected side-effects are almost always paths
to break into the system - think power and timing analysis for two great
examples.  I suppose we have to catch a break sometimes

-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Peter Gutmann]

[EMAIL PROTECTED] writes:

>Second, as soon as one of these guys figures out how to hook the memory
>manager (which may already have happened),

It's been done for awhile by various rootkits.  The first AFAIK was
ShadowWalker, which marked pages to be hidden as non-present and used a custom
page fault handler to allow it to slip in whatever it wanted the victim to
see.

>then the ability to find the otherwise in-core-only malware goes away as your
>act of scanning memory will be seen by the now-corrupted memory manager and
>the malware will be thus relocated as you search such that you are playing
>blindman's bluff without knowing that you are.

There's a large number of variants of this sort of thing.  Some of the most
deviously elegant rootkits use anti-anti-virus scanners to detect antivirus
software from underneath before the AV software detects it.  They then either
de-fang the AV software in some way, or unhook themselves until the AV scan
has passed.  One neat trick used by... ah, forgotton the particular malware,
but it swaps the handle of the process the AV software is trying to terminate
and the AV software itself, so the AV program ends up terminating itself.

There's lots more like this.  You name it, they've done it.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[James A. Donald]

Perry E. Metzger wrote:
> I think Steve is completely correct in the case of
> cryptography. We have a lot of experience of real
> world security failures these days, and they're not
> generally the sort that crypto would fix.

They are the sort that a different sort of way of using
crypto could fix.

Jason:
>> Authentication is exactly what I need in the case of
>> spam/phishing:

Perry E. Metzger wrote:
> People have said that for quite some time. However, I
> doubt it would actually help. In the case of spam, all
> that would end up happening is vast amounts of CPU
> time being spent demonstrating that the made up
> addresses on spam were associated with actual RSA
> keys. (There is no practical limit to the number of
> RSA keys that may be generated.)

First, the phishing case:

Assume that instead of logging in through a possibly
hostile web page, people login using SRP built into the
browser chrome.  Then phishing goes away, because the
man in the middle gets no shared secrets.

Next, the spam case, including spam offering high yield
investments, spam promising millions of dollars stolen
from starving Africans, Indian made viagra, porn sites,
and two hundred and seventy tons of sugar.

To fix spam, we need automatic whitelisting plus
aggressive Baysian filtering.  At present this works
fine, no crypto needed, because the attacker seldom
bothers to adapt to your particular profile.  Tons of
spam descend upon me, and is magically banished, sight
unseen. When impersonation spam attacks become a serious
problem, then we will think about how to use
cryptography to beat them.  Sometimes I have to manually
whitelist people, which Grandma could not do, but that
is a user interface problem - observe that most IM
systems make whitelisting easy enough for Grandma.

> I would actually agree that we can implement operating
> system strategies that make malware harder to write. I
> don't know if it is likely that any current
> techniques, even including the nearly unheard of use
> of formal verification, would actually eliminate
> malware.

OLPC seems very nearly malware proof.  Malware would
require unusual privileges, and there is no easy way to
install software that requires unusual privileges on
OLPC.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Peter Gutmann]

"Leichter, Jerry" <[EMAIL PROTECTED]> writes:

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

Actually VMMs do provide some security, but not in the way you think.  Since
malware researchers typically run malware they're analysing inside a VM, quite
a bit of malware will silently exit (or at least not exercise the "mal" part
of its name) if it detects that it's running inside a VM.  So you can
inoculate yourself against at least some malware by running your OS inside a
VM.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Steven M. Bellovin]

On Thu, 03 Jan 2008 11:52:21 -0500
[EMAIL PROTECTED] wrote:

> The aspect of this that is directly relevant to this
> list is that while "we" have labored to make network
> comms safe in an unsafe transmission medium, the
> world has now reached the point where the odds favor
> the hypothesis that whomever you are talking to is
> themselves already 0wned, i.e., it does not matter if
> the comms are clean when the opponent already owns
> your counterparty.
>
Right -- remember Spaf's famous line about how using strong crypto on
the Internet is like using an armored car to carry money between
someone living in a cardboard shack and someone living on a park bench?

Crypto solves certain problems very well.  Against others, it's worse
than useless -- "worse", because it blocks out friendly IDSs as well as
hostile parties.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Perry E. Metzger]

Jason <[EMAIL PROTECTED]> writes:
> On Wed, 2 Jan 2008, Steven M. Bellovin wrote:
>> Cryptography provides authentication and integrity.  It does not
>> provide authorization, nor does it provide protection against bugs.
>> Your suggested approach -- better OS and better crypto -- is exactly
>> what's failed for the last 25 years.
>
> You're painting with too broad a brush.  Creating artificial life
> failed; security just fails to get adopted.

I think Steve is completely correct in the case of cryptography. We
have a lot of experience of real world security failures these days,
and they're not generally the sort that crypto would fix.

> Authentication is exactly what I need in the case of spam/phishing:

People have said that for quite some time. However, I doubt it would
actually help. In the case of spam, all that would end up happening is
vast amounts of CPU time being spent demonstrating that the made up
addresses on spam were associated with actual RSA keys. (There is no
practical limit to the number of RSA keys that may be generated.)

> did that really come from my bank? 

In the very different case of phishing, I think it would still all
fail. Most people are unable to understand (or outright ignore)
SSL authentication failures to web sites, so I don't see why they
would be disturbed by authentication failures in email from their
bank. We'd also have the problem that lots of email would remain
unauthenticated for years or decades, and that if you got a security
pop-up every time you read such an email, you'd probably learn to
ignore them inside of an hour.

> And you gave examples of OS techniques which mitigate risks in buggy
> apps. Privilege escalation makes bad malware into horrible malware.

I would actually agree that we can implement operating system
strategies that make malware harder to write. I don't know if it is
likely that any current techniques, even including the nearly unheard
of use of formal verification, would actually eliminate malware.

-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Bill Frantz]

[EMAIL PROTECTED] (Ivan Krsti) on Thursday, January 3, 2008 wrote:

>On Dec 31, 2007, at 4:46 PM, 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.
>
>
>It's not, and despite the press handwaving about hypervisor rootkits  
>being the death of all security as we know it, this attack is largely  
>uninteresting in practice. Repeat after me: it's not a real problem,  
>and it's unlikely to become a real problem.

If, as seems likely, we are moving into a world where virtual
machines are a popular security mechanism, the problem isn't
detecting if you are on a virtual machine, because all useful OSes
will expect to be running on a virtual machine.  The problem will be
to detect if the virtual machine is hostile.  That code will
probably have to be part of the virtual machine monitor (VMM)
implementation.  There may be less use for running VMMs in virtual
machines, although we got a lot of use from the ability to run
VM/370 in a VM/370 virtual machine back in the 70's and 80's.


>A walkthrough with pretty pictures, courtesy of the Matasano folk:
>

Neat.  An interrupt at the wrong time would also upset the
TLB/Mapping table mismatch.  I wonder if a VMM could be built to
simulate the mismatch?  Note that on the Intel architecture, there
are certain instructions that behave differently in supervisor mode
and user mode.  These instructions can also be used to leverage VM
detection.

Cheers - Bill

---
Bill Frantz|"We used to quip that "password" is the most common
408-356-8506   | password. Now it's 'password1.' Who said users haven't
www.periwinkle.com | learned anything about security?" -- Bruce Schneier

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[dan]

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


First, it is evident that the malware writers have
reached a level of sophistication where stealth is
more attractive than persistence, i.e., prey are
sufficiently abundant that it does not matter if your
code survives reboot -- you can always get a new
machine soon enough.  Second, as soon as one of these
guys figures out how to hook the memory manager
(which may already have happened), then the ability
to find the otherwise in-core-only malware goes away
as your act of scanning memory will be seen by the
now-corrupted memory manager and the malware will be
thus relocated as you search such that you are
playing blindman's bluff without knowing that you
are.  Third, targetted malware does not defeat the AV
paradigm technically, rather it defeats the business
model as no AV company can afford to craft, test, and
distribute signatures for any malware that does not
already have, say, 50,000 victims.  Fourth, under
so-called Service-Oriented-Architecture, there is no
one anywhere who knows where all the moving parts
are.

The aspect of this that is directly relevant to this
list is that while "we" have labored to make network
comms safe in an unsafe transmission medium, the
world has now reached the point where the odds favor
the hypothesis that whomever you are talking to is
themselves already 0wned, i.e., it does not matter if
the comms are clean when the opponent already owns
your counterparty.

I blogged on this recently (guest for Ryan Naraine)
and it made the top of Slashdot.  Apologies for
boring those who've already seen it.

--dan

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Anne & Lynn Wheeler]

Leichter, Jerry wrote:

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.
  

re:
http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software 
iminent
http://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software 
iminent
http://www.garlic.com/~lynn/aadsm28.htm#8 Death of antivirus software 
iminent


the other claim was that it was assumed that basic systems were built to 
be secure,
so it would have been quite foreign idea it would be necessary to build 
a secure

specific system.

besides the referenced fairly wide use of gov and commercial 
institutions requiring
high integrity systems ... the early virtual machine systems (cp67 and 
vm370)

were also used by commercial time-sharing service bureaus. most of these
created cms "padded cell" modifications, a lot of it was to prevent 
users from

damaging themselves (as opposed to the underlying security that prevented
uses from damaging the system and/or each other).

at least some of these services provided online, concurrent services to
(competitive) wall street firms ... who would be using the online services
for highly sensitive financial activities (as example of integrity 
requirements).


a little related x-over from posting in this thread
http://www.garlic.com/~lynn/2008.html#14 hacked TOPS-10 monitors

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

virtualizaton and security cfp (was Re: Death of antivirus software imminent)

[Sean W. Smith]

With this discussion of virtualization and security, it might be a  
good time to note:






IEEE Security & Privacy
Special issue on virtualization
September/October 2008

Deadline for submissions: 6 February 2008

Visit www.computer.org/portal/pages/security/author.xml to submit a  
manuscript

Guest editors: Samuel T. King (UIUC), Sean W. Smith (Dartmouth)

Virtualization has several properties that make it useful for  
security applications. Traditional virtual machine monitors aspire  
to enforce strong isolation among multiple operating systems (OSes)  
running on the same physical hardware, enable software services to  
be implemented below the OS at a layer usually only accessible by  
hardware, and provide low-level software with convenient  
abstractions of the virtual machineís hardware resources. Other  
approaches aspire to provide multiple virtual but isolated images  
of the same OS installation. These properties helped foster a new  
class of virtual-machine- based security services and made  
virtualization a staple of many enterprise computing environments.


A common topic in the early days of computing, virtualization has  
recently seen a resurgence of commercial and research interest.  
Consequently, the security implications of virtualization  
technology are the topic of the Sept./Oct. 2008 special issue of  
IEEE Security & Privacy magazine. We are looking for feature  
articles with an in-depth coverage of topics related to  
virtualization technology and how it applies to security. Among the  
potential topics are:


--Virtualization for intrusion detection
--Virtualization for forensic analysis of compromised computer systems
--Virtualization for analyzing malicious software
--Hardware support for secure virtualization
--Security interfaces between VMMs and operating systems
--Securing applications using virtualization
--Securing attacks using virtualization
--Security analysis of virtualization

The above list is neither complete nor closed. Authors are  
encouraged to submit articles that explore other aspects of  
virtualization and its application to security. Submissions will be  
subject to the peer-review methodology for refereed papers.  
Articles should be understandable to a broad audience of people  
interested in security and privacy. The writing should be down to  
earth, practical, and original. Authors should not assume that the  
audience will have specialized experience in a particular subfield.  
All accepted articles will be edited according to the IEEE Computer  
Society style guide.




-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Ivan Krstić]

On Dec 31, 2007, at 4:46 PM, 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.



It's not, and despite the press handwaving about hypervisor rootkits  
being the death of all security as we know it, this attack is largely  
uninteresting in practice. Repeat after me: it's not a real problem,  
and it's unlikely to become a real problem.


A walkthrough with pretty pictures, courtesy of the Matasano folk:



Cheers,

--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Bill Frantz]

[EMAIL PROTECTED] (Jason) on Wednesday, January 2, 2008 wrote:

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

I fully agree that a better OS would go a long way toward helping in
the battle.  We even know some techniques for building a better OS. 
Consider plash , and Polaris
, both of
which run programs for a user with less than that user's privilege. 
This technique helps prevent viruses from infecting computers by
denying them write privileges to system files and most of the user's
files.

The model that any program a user runs can do anything that user is
permitted to do is fundamentally broken.  It is the model that all
current popular OSes support, so in that sense these OSes are
insecure.  The only mistake users make in many cases is running
software with bugs such as buffer overruns, where the virus then
uses the user's privileges to take over their system.  In these
cases, IMHO, blaming the user is inappropriate.  And in all cases,
OSes should give the user more support in making sound decisions. 
See for example: 

Cheers - Bill

-
Bill Frantz| The first thing you need when  | Periwinkle
(408)356-8506  | using a perimeter defense is a | 16345 Englewood Ave
www.pwpconsult.com | perimeter. | Los Gatos, CA 95032

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Jason]

On Wed, 2 Jan 2008, Steven M. Bellovin wrote:

Cryptography provides authentication and integrity.  It does not
provide authorization, nor does it provide protection against bugs.
Your suggested approach -- better OS and better crypto -- is exactly
what's failed for the last 25 years.


You're painting with too broad a brush.  Creating artificial life failed; 
security just fails to get adopted.


Authentication is exactly what I need in the case of spam/phishing: did that 
really come from my bank?  Did it come from someone I've interacted with 
before?  Some people sign their messages automatically, some people's mail 
readers automatically check.  It works great for those who put in the effort.


And you gave examples of OS techniques which mitigate risks in buggy apps. 
Privilege escalation makes bad malware into horrible malware.


So good OS and crypto are important, and we've done good work in learning how 
to build them correctly.  You're right that they've failed in the marketplace, 
but economics and psychology were the motivating factors.  We just need to 
send our grad students over to those departments to figure out how to overcome 
those hurdles.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[James A. Donald]

> 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

Books from twenty years ago will not tell you how to
make your impregnable fortress useful, usable, and
convenient.  Impregnable fortresses tend to be located
at the North Pole, and customers fail to show up.

Further, often what is built is an impregnable wall,
rather than an impregnable fortress.  The other three
walls are overlooked, or if overlooked, there is no way
in, or if a way in is provided, anyone can go through
it.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Steven M. Bellovin]

On Wed, 2 Jan 2008 21:26:47 + (UTC)
Jason <[EMAIL PROTECTED]> wrote:

 
> 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.
> 
~~20 years ago, after the Internet Worm, I went and reread the Orange
Book.  I concluded, to my horror, that *nothing* in it, including an
A1-rated system, would have stopped the worm from spreading.  Being
rather new to the theoretical security game (though I'd caught my first
hackers around 1971), I asked someone older and wiser.  "Oh, no; a B2
system would have prevented it."  I asked how.  "B2 requires a thorough
search for bugs."

Worms and viruses have essentially nothing to do with the operating
system.  As long as whatever context the vulnerable application is run
in -- the mailer, the browser, the word processor, whatever -- can
write to the network or to a file, the malware can spread.

Another approach is to run such things at a lower privilege level.
(Vista does that with IE7.)  The problem is that you sometimes have to
cross the barrier; that's another way the malware can spread.
> 
> 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).
>
Cryptography provides authentication and integrity.  It does not
provide authorization, nor does it provide protection against bugs.
Your suggested approach -- better OS and better crypto -- is exactly
what's failed for the last 25 years.

If you included all applications as part of the OS, you'd be right --
except that it isn't possible to secure such a code base.

References:
http://www.csl.sri.com/users/neumann/insiderisks06.html#196
http://www.cs.columbia.edu/~smb/papers/sub-browser.pdf
http://vx.netlux.org/lib/vtd01.html
http://homes.cerias.purdue.edu/~spaf/tech-reps/823.pdf


--Steve Bellovin, http://www.cs.columbia.edu/~smb

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[alien]

Today's VMMs aren't even designed to fit the formal criteria for a VMM
(at least as expressed, intelligently, by Popek and Goldberg back in the
70s).  VMM-aware malware leverages this: for example, by making calls to
VMware's "backdoor" communications channel from the guest (ie. jerry.c).
If the "equivalence" principle were actually upheld, this wouldn't be
possible-- but then again, users wouldn't have all those handy features
like cut-n-paste from guest to host.

Sherri



Leichter, Jerry wrote:
> 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 [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

RE: Death of antivirus software imminent

[Leichter, Jerry]

| 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 [EMAIL PROTECTED]

RE: Death of antivirus software imminent

[Charles Jackson]

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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Leichter, Jerry]

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 [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Jason]

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 [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Angelos D. Keromytis]

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

http://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.html

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 [EMAIL PROTECTED]


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Anne & Lynn Wheeler]

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.html

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 [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Bill Frantz]

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 [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Ivan Krstić]

On Dec 29, 2007, at 6:37 PM, Anne & Lynn Wheeler wrote:

Virtualization still hot, death of antivirus software imminent


My, that sounds awfully familiar:


I note that, come the January OLPC software update, I will be using my  
XO laptop for all my e-banking and related needs. It provides a  
drastically more secure platform for doing so than any mainstream  
computer I know exists.


--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Death of antivirus software imminent

[Sherri Davidoff]

Anne & Lynn Wheeler wrote:
> Virtualization still hot, death of antivirus software imminent, VC says
> http://www.networkworld.com/news/2007/121707-crystal-ball-virtualization.html

Interesting how "virtualization" seems to imply "safe" in the public
mind (and explicitly in that article) right now I'm sure with the
increasing use of virtualization, we'll start to see more VMware-aware
malware and virtual machine escapes in the wild. Another example of
putting many, many eggs in the same basket.

Here's a good article about the first public VMware escape, which
Intelguardians demonstrated at SANSFIRE this summer:
(Note: I'm biased, having worked on this project.)
http://www.pauldotcom.com/2007/07/

What boggles my mind is that despite this, the DoD has still decided to
rely on virtualization software to keep classified and unclassified info
on the same physical systems:
http://www.internetnews.com/storage/article.php/3696996

Sherri



Anne & Lynn Wheeler wrote:
> re:
> Storm, Nugache lead dangerous new botnet barrage
> http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1286808,00.html
> 
> from above:
> 
> The creators of these Trojans and bots not only have very strong software 
> development and testing skills, but also clearly know how security vendors 
> operate and how to outmaneuver defenses such as antivirus software, IDS and 
> firewalls, experts say. They know that they simply need to alter their code 
> and the messages carrying it in small ways in order to evade signature-based 
> defenses. Dittrich and other researchers say that when they analyze the code 
> these malware authors are putting out, what emerges is a picture of a group 
> of skilled, professional software developers learning from their mistakes, 
> improving their code on a weekly basis and making a lot of money in the 
> process.
> 
> ... snip ...
> 
> ... and somewhat related
> 
> Virtualization still hot, death of antivirus software imminent, VC says
> http://www.networkworld.com/news/2007/121707-crystal-ball-virtualization.html
> 
> from above:
> 
> Another trend Maeder predicts for 2008 is, at long last, the death of 
> antivirus software and other security products that allow employees to 
> install and download any programs they'd like onto their PCs, and then 
> attempt to weed out the malicious code. Instead, products that protect 
> endpoints by only allowing IT-approved code to be installed will become the 
> norm.
> 
> ... snip ...
> 
> and post about dealing with compromised machines
> http://www.garlic.com/~lynn/2007u.html#771 folklore indeed
> 
> mentioning sophistication in other ways:
> 
> Botnet-controlled Trojan robbing online bank customers
> http://www.networkworld.com/news/2007/121307-zbot-trojan-robbing-banks.htm
> 
> from above:
> 
> If the attacker succeeds in getting the Trojan malware onto the victim's
> computer, he can piggyback on a session of online banking without even
> having to use the victim's name and password. The infected computer
> communicates back to the Trojan's command-and-controller exactly which
> bank the victim has an account with. It then automatically feeds code
> that tells the Trojan how to mimic actual online transactions with a
> particular bank to do wire transfers or bill payments
> 
> ... snip ...
> 
> there have been some number of online banking countermeasures for
> specific kinds of system compromises  like keyloggers ... but they
> apparently didn't bother to get promises from the crooks to only limit
> the kinds of attacks to those exploits.
> 
> some related comments on such compromised machines
> http://www.garlic.com/~lynn/aadsm27.htm#66 2007: year in review
> http://www.garlic.com/~lynn/aadsm28.htm#0 2007: year in review
> 
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]