Message-ID: <200402040705.CAA10133@Sparkle.Rodents.Montreal.QC.CA>
Date: Wed, 4 Feb 2004 01:27:07 -0500 (EST)
From: der Mouse <mouse@...ents.Montreal.QC.CA>
To: bugtraq@...urityfocus.com
Subject: Re: getting rid of outbreaks and spam (junk) [WAS: Re: RFC: virus handling]


OK, I guess I'll brave the storm of incompetently-run "out of the
office" autoresponders and boneheaded C/R systems yet again.

> 1.It is clear that as notifications are today, they are *mostly*
> plain and simple spam.

I agree with you.  They are unsolicited, bulk, and email; ergo, spam.

> Why do I believe that?

> Since they usually contain information regarding getting a brand new
> AV, but not about the virus or how to get cleaned.

Adding information about the virus or how to disinfect would not help
one bit.  I do not have the virus, I cannot have the virus, I have no
use save academic interest in details about the virus or about how
people who have it might get rid of it; adding such information to the
already-useless notifications I get will make them no more useful (and
in fact less so because it will make them bigger).

Also, it will not make them any less unsolicited, any less bulk, or any
less email; they will still be spam.

> 2. In a broader view, notifications ARE currently the problem rather
> than a solution.

Agreed.

> The AV industry is built on reaction rather than prevention.  Adding
> new signatures is still the #1 tool in the fight against malware.
[...]
> If backbones filtered the top-10 current outbreaks,

I suggest you talk to a backbone network engineer before making such
suggestions.  The backbones do not handle email as such; they handle
packets that, taken together, make up email sessions (and many other
things).  The difference is immense.  In particular, the backbones
cannot associate one packet in an SMTP session with the next in the
same session; while in theory they could be made to, in practice it
would be far, far too resource-intensive, especially given how close to
the line they are running as it is.

> with non-intrusive means such as for example running MD5 checksum
> checks against attachments,

Can't be done.  Some of the reasons why:

- Knitting packets together into TCP data streams (necessary to
  identify attachment boundaries) demands orders of magnitude more
  resources (both cycles to inspect the packets and memory to store
  them) than are available.

- Knitting packets together into TCP data streams demands that all
  packets making up the stream follow the same path.  Anyone who thinks
  the core routing tables are that stable needs a reality check.
  (Granted, 50% success would be better than nothing, but not much,
  especially in view of the cost in the form of half-completed state
  sitting around waiting for packets that went another way.)

- MD5 is a relatively expensive checksum to compute, thus even further
  overdrawing the cpu-cycle budget; since many MD5s will have to be in
  progress at any one time, this also exacerbates the memory lack.

- Slight randomizations in virus payload have been a standard tactic
  for years; if this is done, it will simply become universal (since
  then each viral payload will have a different MD5).

- Even if somehow all the above went away, by the time the attachment
  ends and the MD5 is computed, it's too late; it's already been sent.
  All that can be done at that point is to disrupt the SMTP connection,
  such as by RSTing it rather than sending the closing dot, and even
  that will simply make the sender retry repeatedly, thus replicating
  the waste many times.  (If it's a smarthost's MTA, that is.  It will
  stop viral SMTP engines that don't bother retrying, but again, such
  measures will simply make smarthost-using viruses even mroe
  ubiquitous than they already are.)

- People won't stand for it.  I know I certainly wouldn't.

> True, it may cause a cry of "the government spies on us, but with the
> current economic troubles outbreaks cause, can we really use that
> excuse anymore?  Doesn't the police regulate speeding?

Roads are a shared public resource.  The backbones you are making so
free with are privately owned.  If you want the various national
governments (yes, plural) to expropriate them all as a first step, you
should at least be upfront about it - and you will get a _lot_ more
resistance to your plan.

> There are enough solutions out there for spam and malware, they are
> mostly not being implemented for different political and commercial
> reasons.

Sure.  Many of the solutions I've seen are akin to killing off a tumor
by cremating the patient: they'll work but are excessive.  The others
won't work.  There may be something that avoids both those problems,
but I've yet to see it.

> 4. As far as the IP-ADDRESS@isp goes, it IS a good idea, but not a
> very practical one in my opinion.  Allow me to explain why.

You've explained why it's not practical.  How about explaining why you
think it's a good idea?  (I think it's a terrible idea; it has endless
downsides and, as far as I can see, no real upside at all - suppose I
get hit from 12.34.56.78.  So I send to 12.34.56.78@...where?  If I'm
going to look it up in ARIN/RIPE/etc, I might as well just use the
abuse contact listed there anyway.  Furthermore, if it's a dynamic
dialup, it could easily have been used by a dozen different users
during the time between the offense occuring and my sending a report;
which one gets it?  What if my computer's clock is 47 minutes wrong?)

> [...] the real problem which is ISP's not doing much about ABUSE
> REPORTS or USER SECURITY.

Right.  But what can be done about it?  You mention "the law"; what do
you think "the law" (as if there were a single "the law" on the net)
should, or even could, dictate?

> I don't understand why the biggest problems of the Internet should be
> commercialized and thus become static, rather than solved.

Because nobody's managed to solve them yet.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@...ents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Powered by blists - more mailing lists