Subject: RE: [Asrg] DCC and IP checksums

From: Paul Judge <[email-masked]>
Date: Thu, 13 Mar 2003 06:15:59 -0500

Gentlemen,

If you wish to continue this discussion, perhaps you can do so in private
communication. 

There are over 400 subscribers to this mailing list. For the most part these
are busy individuals that signed up for a research mailing list to
understand and contribute to solving the spam problem. They are not
interested in scoring a debate match between two men and a sidekick.

To all: With every post to this list, please ask yourself if your message
contains an idea or contribution that is worthy of sitting in the mailboxes
of 400 busy and intelligent individuals. Remember, we are here to stop (not
produce) unwanted messages.

Thanks,
Paul

_______________________________________________
Paul Q. Judge        [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, March 13, 2003 12:06 AM
> To: [email-masked]
> Subject: Re: [Asrg] DCC and IP checksums 
> 
> 
> On Wed, 12 Mar 2003 18:23:36 PST, "Hallam-Baker, Phillip" 
> <[email-masked]>  said:
> 
> > For the record, the value in separating authentication and 
> > authorization is uniquely a function of an environment 
> where there is 
> > a great variation in the rights which individuals may hold. In 
> > environments where there is no such variation in rights 
> there is not 
> > an intrinsic value in authentication as a distinct step.
> 
> Hmm.. Vern, he's got us there...
> 
> A truly sad state of affairs, but he *does* have us there...
> 
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Thu, 13 Mar 2003 14:08:57 -0500

> interested in scoring a debate match between two men and a sidekick.

On the flip side, I'm writing this as yet *ANOTHER* worm is crawling around
and poking port 445 all over the place.

http://isc.incidents.org/port_details.html?port=445

And there's Code Red outbreaks STILL.

I'll spell it out:  Not many of the proposals I've seen so far address the
issue of what happens once "spammer" meets up with "Outlook/IE worm" and/or
"DDOS zombie network".  The average security posture Out There is *abysmally*
low, and the machines are for the vast majority a monoculture developed
around a broken security model.  Several ideas have overlooked the concept
that the remote end could be lying to you, but almost all make the implicit
assumption that the *local* end is trustable.

And I'm not at all convinced that's true at most sites.

---

From: [email-masked]
Date: Fri, 14 Mar 2003 00:39:03 -0800 (PST)

Actually one of my notes was exactly on this issue. I concuded that the
best is to use local filters and separate attachments (such as .exe, .scr, 
.bat, etc) from the email and deliver email to recepient without an 
attachment but include a instead a note/attachment that it was present  
with information on how attachment can be downloaded from the local ISP
server - possibly by using IMAP server with IMAP url indicating exactly 
what message to get from the server. This saves time for users when 
receiving email over slow connection (dialup) and for well-known viruses, 
the users would not even try to download it (plus checking email for 
viruses on common IMAP server is easier setup for ISP, since many use unix 
servers for mail delivery but most antiviruses run from windows platforms)
(To be fair - this idea came when I was reading somebody elses proposal on 
delivering not the email itself but a link where it can be picked up at 
the sender's server by IMAP - similar concept to sending user to read 
email on the website)

Additional thoughts on the issues included on how to verify that email is 
"virus free" and has been checked by anti-virus by the sender by using 
special certificate generated (automaticly) by antivirus based on content 
of email (simple hash) and based on its own certificate - that anti-virus 
certificate can of course be checked on antivirus website, so it creates 
fairly good trust system.

Now the above not address your point that local end can not always be trusted
and email-only hoaxes can still propogate just fine, but it addresses 
larger problem of security & viruses that get sent through email.

---

From: [email-masked]
Date: Fri, 14 Mar 2003 08:56:36 -0500

> fairly good trust system.

Just remember that this check done *by the sender* is close to useless:

1) As written, it doesn't contain any verification that a *current* template
of signatures was used - I've actually gotten mail that was stamped "this
mail certified virus-free by LlamaWare 1.2" and contained a virus anyhow,
because it's signature database was *literally* 2.5 years out of date.

2) Either the sending system has a virus, or it doesn't.  If it doesn't,
it doesn't matter if it got scanned.  If it does, I have no guarantee that
said scanner hasn't been fooled by a rootkit.

3) Now imagine a virus that injects itself and then forges a "virus free"
signature for itself (remember - if the virus scanner has enough info to
generate a cert, any malware that gets loose on that machine has enough info
to forge the same cert).

Now, to be fair, the outdated signature issue and the rootkit issue both
*DO* also apply at the local end.  On the other hand,  the local end is
under my control (well.. OK.. the guy in the next cube over ;) so I can
make informed decisions regarding whether to trust its opinions...

---

From: Matt Sergeant <[email-masked]>
Date: Fri, 14 Mar 2003 14:45:39 +0000

> generate a cert, any malware that gets loose on that machine has 

4) there's a window of opportunity between the virus coming out and the 
signature being created.

---

From: [email-masked]
Date: Fri, 14 Mar 2003 10:04:21 -0500

> 4) there's a window of opportunity between the virus coming out and the 

How is that different than my (1)?  I was using an extreme example of years,
but as we all know, sometimes it's out of date by only hours. It doesn't make
much difference whether you've failed to download a template or the vendor
hasn't posted one - if your template doesn't have the signature for an already
existing virus, it's non-current. ;)

---

From: [email-masked]
Date: Fri, 14 Mar 2003 08:37:12 -0800 (PST)

> because it's signature database was *literally* 2.5 years out of date.
Certificate being included with email is certificate has antivirus 
ceertificate as a parent (antivirus program signs the certificate, which 
itself is signed by antivirus vendor). In order to "fake" it virus should 
be really smart and have debugged code for that particular antivirus to 
find how to do it. It would also assume that new certificate is issued by 
antivirus vendor every time you download updated list of virus definitions 
- and in fact the certificate is used to verify that downloaded list of 
virus definitions is truly from antivirus vendor.
 
> said scanner hasn't been fooled by a rootkit.
I agree with you. As I said in the beginning none of my notes offer 
complete solutions, but I examine techniques available - write pros & 
cons and mark the ones that offer most possibility of success. 

The system above combined with checking emails on the receiving end (and 
sending only the link to suspicious attachment) offers very good chance of
of never letting virus be delivered even if client does not have antivirus 
program (though it would still be recommended that they do).

> generate a cert, any malware that gets loose on that machine has enough info
Virus has to be very very smart to be able to do this and would have to 
know howto generate signatures for each version of antivirus program and 
each antivirus program user may have. 

> make informed decisions regarding whether to trust its opinions...
The signature has less trust built into it then scanning it locally. But 
it helps nevertheless for those who do not have antivirus installed. 

People should still buy and install antiviruses so that they can scan 
incoming email and also scan and sign outgoing email as well. 

-- 
William Leibzon
Elan Communications Inc. 
[email-masked]