Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

RE: Backdoor not recognized by Kaspersky
From: Nick FitzGerald <nick () virus-l demon co uk>
Date: Fri, 05 Mar 2004 02:27:05 +1300

"Larry Seltzer" <larry () larryseltzer com> to 'Mike Barushok':

SMTP auth does not help at all. A virus that delivers email via it's
own SMTP engine completely bypasses the end users ISP server(s). And if
the recipient server does not allow incoming mail from wherever it is
presented from, then incoming mail will simply be broken unless there
is some sort of SPF. 

Yeah, exactly, that's the point. SMTP AUTH plus something like
SPF/CID/DK would stop all the existing worms from operating.  ...

Larry -- I don't give a flying f*ck about the current worms.  Most of 
them have a rather limited life already.  The future worms are the ones 
that interest me because SPF, etc has been promoted through utter BS as 
"preventing" mass-mailing viruses (among other things that it does not 
do).  SPF, etc won't prevent future mass-mailers for the reasons I, and 
several others, have already explained in this thread.

...  Mail sent
through their own engines would be rejected by SPF/CID/DK. 

And that's the "problem" -- mail sent through your MUA's "own engine" 
can get through SPF just fine (so long as you accept a whole raft of 
stupid, pointless and unnecessary to the stated purpose as they will 
only hinder law-abiding Email users anyway, restrictions).  What makes 
you think that the next generation of viruses won't be written to work 
like (or even go back to using) your MUA?

And as for SMTP AUTH -- programmed identity theft will deal with that 
just as key loggers and other data stealers work now.

But, SPF, caller-ID, and Domain keys all have major unsolved issues
with forwards, aliases, corporate employees checking their work mail
and needing to reply through their home connection ISP, but with their
company 'From: ' address and several other common scenarios. Until
their is universal adoption of some add on to SMTP, nobody can reject
all non-conforming mail safely. 

It's not hard to imagine the largest ISPs and large corps accepting
it, at which point it would become necessary for others to accept it or
risk having their mail shut out. 

So, because Hotmail (say) prefers a particular form of "sender 
authetication" and Hotmail has no concern for the vagaries of others', 
RFC-compliant use of the longest running of the highly useful Internet 
protocols, all those others should be inconvenienced because of 
Hotmail's size and clout in the market?

It will be a sad day for "the Internet" if that is what happens...

All implementations create a much greater load on DNS. 

Greater, yes. Much greater, I'm not so sure. Verisign doesn't think
it's a substantial extra load. The DNS data could very reasonably be
cached. 

Don't know, don't care...

The real issue is that their is no possible algorithmic solution to
rejecting email reliably based on any of its source, its content, or
any combination. 

So SPF/CID/DK don't work? They reject based on domain

See above.  You seem to have this weird idea that because today's spam 
and mass-mailers forge sender information tomorrow's spam and mass-
mailers _must_ continue to do so.  This shows such a grievous lack of 
the most basic of pertinent historical knowledge it would be laughable 
were the consequences and wasted effort for no benefit not so great, 
should folk suffering from your level of misunderstanding prevail.

If the mail is not accepted, laws prohibit silently discarding it. 

I've never heard this before. What law?

Yes -- that is an overstatement.  However, the RFCs/STDs covering SMTP 
take a pretty sharp stand on what an implementation should and must do 
if it "accepts" a message and then cannot deliver it to (any of the) 
addressees...


Regards,

Nick FitzGerald

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]