lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.21.0403061911010.12752-100000@kcisp2>
From: mikehome at kcisp.net (Mike Barushok)
Subject: Backdoor not recognized by Kaspersky


On Thu, 4 Mar 2004, Larry Seltzer wrote:

> >>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. Mail sent through their own engines would be rejected
> by SPF/CID/DK. 
> 
> >>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. 

I expect we may have to publish DNS records to get our users mail
to be accepted. We will definitely not have to lookup their
published records to decide whether to accept their mail.

(and see below)

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

We had a server that is not a primary MX, but secondary or
tertiary for a number of domains come to nearly a complete
standstill due to a couple of bogus records being returned
when it was trying to find MX's to bounce some undeliverable
mail. DNS is actually a lot more fragile than most people
realize. Publishing the record in zone files, and propogating
the records is not that much of an issue. Doing the extra
lookups and interpreting the results algorithmically is
a major issue. DNS works quite well for what it is intended
for, but anything beyond the simple, easily interpreted
records that are in univeral use would require major hardware
and software upgrades that are difficult to sell to management
due to the fact that we have no 'revenues' that come from
DNS (in their way of thinking).

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

Well, here is the thing, if there are no TXT type records in the
zone file for a given domain, but there is not a NXDOMAIN returned
do you reject that mail? That would require simultaneous
implementation world wide, or result in rejecting a lot more
legitimate email than spam. 

> 
> >>If the mail is not accepted, laws prohibit silently discarding it. 
> 
> I've never heard this before. What law?
> 
> Larry Seltzer
> eWEEK.com Security Center Editor
> http://security.eweek.com/
> larryseltzer@...fdavis.com 
> 
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 


Powered by blists - more mailing lists