RE: Clueless anti-virus products/vendors (was Re: Sober)

Mailman List Mirror (Read Only)
1

What about all the viruses out there that don't forge addresses?
Sending a warning message makes sense for these. Unless someone has
done the research to determine the majority of viruses forge addresses,
you really can't complain about the fact that the default is to warn.
Calling vendors 'clueless' because a default doesn't match your needs is
a little extreme, don't you think? The ideal solution would be for the
scanning software to send a warning only if the virus detected is known
to use real addresses, otherwise it won't warn.

Chuck

2

What about all the viruses out there that don't forge addresses?

What virus in the past 2 years doesn't forge the from address?

George Roettger

3

Better safe than sorry. Unless you can determine that it isn't forged, you shouldn't be sending anything because there is so much out there forging From: addresses (or To: for that matter, with Bcc:).

So, this isn't about ideal vs ok-close-enough. Don't send me crap unless you have a reasonable level of confidence. I don't believe that you can pass a straight face test with virus scanning responses on that one.

If you can, I think you need your head examined :wink:

4

True, but the "capability" has been in most AV software for quite a long time
now to know which ones "forge" and which do not. Clamav has a "list" of
which virii are "forging" and which are not - I am reasonably certain that
most other AV products have the same information at hand (a quick search of
Symantec confirms that they know [ref sober worm, para 23, From:
(spoofed)). So while I agree with your basic concept of notifying someone
that they are infected - when you can notify the "right" person - blanket
notifications are more trouble than the virus itself in many cases. And yes,
as of yesterday I have more "blowback" from sober than from the worm
itself....

5

A-V companies are in the business of analyzing viruses. They should
*know* how a particular virus behaves.

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

6

Date: Sun, 04 Dec 2005 23:04:52 -0500
From: Steven M. Bellovin

A-V companies are in the business of analyzing viruses. They should
*know* how a particular virus behaves.

The cynical would say they _do_ know, and "accidental" backscatter is a
way to advertise their products. :wink:

Eddy

7

An even more cynical way would be to say that most antivirus companies aren't in the business of analyzing viruses - they are in the business of selling antivirus software.

I believe that is the fundamental problem.

Jamie

8

What about all the viruses out there that don't forge addresses?

Not that there are nearly as many -- the main scourge is sender-forging
worms by a better than 90%/10% margin -- but I very specifically mentioned:

> > (Virus "warnings" to forged addresses are UBE, plain and simple.)

I think that was pretty clear.

Sending a warning message makes sense for these. Unless someone has
done the research to determine the majority of viruses forge addresses,

Are you living on Earth in 2005? Unless your filters are VERY strict, no
research should be necessary; look at your own mailbox[es]. If you don't
know that most worm-viruses forge senders these days, you haven't been using
Internet e-mail long enough. :sunglasses:

That said, it takes only a cursory glance through the worms listed on
Symantec's or F-Secure's or Sophos's web sites in reverse chronological
order to see, very clearly, that *nearly every* worm in recent history
forges sender addresses. Finding three or more worms in the past two years
that don't forge is a challenge for the bored reader.

Some do it for a very good reason -- in the eyes of the worm's writer, mind
you. A worm is more likely to get through if the user in envelope-FROM has
some sort of relationship with the recipient, because so many sites use
weighted scoring that includes auto-whitelist bias. To a worm writer, just
using the address in the luser's settings isn't enough, as folks are
starting to understand "don't click on any random attachment." So, gambling
on the luser having a circle of friends close enough to know each other, the
worm forges many different combinations. (If you want more details on this
reasoning, take it off-list.)

Calling vendors 'clueless' because a default doesn't match your needs is
a little extreme, don't you think?

The vendors sending worm-virus "warning" UBE are indeed clueless now,
because they aren't paying attention to (often their own!) virus statistics
showing that the majority of worm-viruses forge sender addresses today.

Let me repeat myself:

> > (Virus "warnings" to forged addresses are UBE, plain and simple.)

Not sending UBE is not just "my needs"; I think we can both agree on that.

To extend that concept, virus "warnings" triggered by worm-viruses for which
the forgery status is unknown is either UBE or very close to it.

With the massive amount if spew that is forged, any warning option that is
not absolutely confined to trigger on problem mail *known* not to be forged
is a part of the problem, not part of the solution. The option for warning
on forged senders shouldn't just be off -- it should not exist.

The ideal solution would be for the scanning software to send a warning
only if the virus detected is known to use real addresses, otherwise it
won't warn.

Symantec reportedly did this at long last in one of their products recently
(see SPAM-L@PEACH.EASE.LSOFT.COM archives for details). I truly hope others
follow suit. However, unless the option to warn forged senders is removed
entirely from their products, anti-malware vendors still have a large amount
of fault on their shoulders.

Things like clamav have had the option properly separated for some time, but
I'm mainly counting the slow-moving, commercial anti-malware products in the
prior pragraph.

9

This has also been said before, but... they are also in the business of
SELLING their product. It seems that the 'default' (note I don't either:
use av, nor scan emails for virii so I'm not sure what defaults to what...
just use something other than outlook and you can care less about it) is
possibly there for advertising effect more than anything else :frowning:

Hey, bob's company stopped this virus with $PRODUCT_12, why aren't we
using that product $VP_O_IT ??

10

What about all the viruses out there that don't forge addresses?

As others have noted, these are so far lost in the noise as to not be a factor.

Sending a warning message makes sense for these.

Why? Because you need to be the one to tell the sender they are infected? Let sites patrol their own users.

Furthermore, if you did your virus scanning during the SMTP transaction, you'd be able to send back a 5xx error response during the transaction, thereby avoiding any concern about spamming an innocent third party.

  Unless someone has
done the research to determine the majority of viruses forge addresses,
you really can't complain about the fact that the default is to warn.

As others have noted, the vendors can and should know.

Calling vendors 'clueless' because a default doesn't match your needs

Excuse me, I think you may notice that a LOT of folks have piped up on this issue. The simple fact is as configured many vendors spam third parties adding to the noise floor. While backbone operators might in fact make a bit extra as a result, those of us who actually pay for bandwidth do not appreciate it. We certainly can and do blacklist sites that hammer us with bogus bounces, just the same as we'd block any company knowingly sending us undesired email.

is
a little extreme, don't you think? The ideal solution would be for the
scanning software to send a warning only if the virus detected is known
to use real addresses, otherwise it won't warn.

See question above, re: why do you think it's your systems' place to police the rest of the Internet, sending warnings out? Either reject virus-laden email during the SMTP session, or quietly own it (and dispose of it).

11

Three responses.

First, these are pretty much a minority nowadays: so unless someone
wants to code AV responses on a case-by-case basis, the best default
is "don't respond, ever".

Second, rejecting virus-contaminated traffic during the SMTP phase
completely alleviates the need to address this question, since no
outbound mail is generated.

Third, put the first two points aside. Let's suppose, for a moment,
that there existed a completely reliable mechanism for figuring out
the real sender (in the sense of "the owner of the infected system")
for a particular virus-contaminated message.

Think about what would happen if the 100 or 1000 or 10000 or 100000
people getting outbound viruses from that user all generated responses.

The first effect would be to double the quantity of useless mail
messages traversing the Internet.

The second effect would be to hammer the user's mailbox and whatever
mail server it happened to be residing on. (Consider how this effect
would be multiplied if many users of X all had infected systems sending
SMTP traffic directly, but of course were all receiving inbound mail via
X's mail server(s).)

The third effect would really be a non-effect, as the user's most
likely response (thanks to years of conditioning imposed by the
problem we're discussing here) would be to do nothing: experience
has taught users that such warnings are bogus and can safely be ignored.
The user's second-most-likely response would be indignant denial (despite
logs showing positive identification). The user's third-most-likely
response would be report the responses as spam and/or block the senders.

Bottom line: nothing good can come of generating outbound mail in
response to rejected inbound mail; the best course of action is to
issue the appropriate 5XX response and be done with it.

---Rsk

12

It is common to find detailed descriptions offered by the company that indicates the behavior of the detected virus, which often includes spoofing the bounce-address. A less than elegant solution as an alternative to deleting the message, is to hold the data phase pending the scan. Another solution would be not returning message content within a DSN. This would mitigate the distribution of viruses, as well as forged bounce-addresses sent to a backup MTAs as a method for bypassing black-hole lists. Would changing what is returned within a DSN in all cases be a solution?

-Doug

13

No. You're still sending a DSN to a destination that you know beforehand
is incorrect.

14

A less than elegant solution as an alternative to deleting the message, is
to hold the data phase pending the scan.

Contrary to your vision of this option, it is not only elegant; it happens
to be the *correct* thing to do.

Dropping the message on the floor is arguably stretching the bounds of
RFC2821. If a message is going to be dropped because of a policy (such as a
worm/virus flag), you really should be rejecting after DATA with a RFC1893
5.7.x extended result code.

Another solution would be not returning message content within a DSN.

If you're still sending to a forged address, how is this not still UBE...?

15

Holding at the data phase does usually avoid the need for a DSN, but this technique may require some added (less than elegant) operations depending upon where the scan engine exists within the email stream. Waiting for the scan to complete adds stack overhead (assuming a good black-hole list is being used). Albeit small, there is never 0% false detections of malware. It would seem that when a DSN is required, as a general practice, the DSN should not include message content. This should at least thwart this vector being used to spread malware and spam. Preventing the spread of a virus seems key. There is always BATV to clean-up spoofed bounce-addresses in the meantime.

-Doug

16

> > A less than elegant solution as an alternative to deleting the message, is
> > to hold the data phase pending the scan.
>
> Contrary to your vision of this option, it is not only elegant; it happens
> to be the *correct* thing to do.

Holding at the data phase does usually avoid the need for a DSN, but this
technique may require some added (less than elegant) operations depending upon
where the scan engine exists within the email stream.

Not my problem. I don't need or want, and should not be hammered with,
virus "warnings" sent to forged addresses -- ever. They are unsolicited (I
didn't request it, and definitely don't want it), bulk (automated upon
receipt of viruses by the offending server), e-mail... thus UBE.

It's up to the server operator to choose how to handle virus protection in
the mail system, without generating any mail whatsoever to forged or
unknown-if-it-is-forged senders.

It would seem that when a DSN is required, as a
general practice, the DSN should not include message content.
This should at least thwart this vector being used to spread
malware and spam. Preventing the spread of a virus seems key.

I, frankly, don't care about the issue of whether or not a "warning" message
includes the virus that triggered it; you've missed the point.

I care about the fact that these "warnings" are UBE, at levels that have
been peaking above those of direct spam from what I can see.

Generated virus "warnings" must not go to a known forged sender, or to a
sender for which the forgery status is unknown. If you cannot *guarantee*
that the address in MAIL FROM:<> is correct, and cannot reject at SMTP time,
your only options are to quarantine, discard, or allow delivery. Do not
send a DSN; do not pass Go; do not collect US$200.

There is always BATV to clean-up spoofed bounce-addresses in the meantime.

And other methods (DK, SPF, SID, choose your poison). However, if the
server cannot verify that the MAIL FROM:<> is not forged with reasonable
certainty, the server should not send a DSN, period. Otherwise, it's a
direct contributor to the UBE problem.

17

Holding at the data phase does usually avoid the need for a DSN, but this
technique may require some added (less than elegant) operations depending upon
where the scan engine exists within the email stream.

Not my problem. I don't need or want, and should not be hammered with, virus "warnings" sent to forged addresses -- ever. They are unsolicited (I didn't request it, and definitely don't want it), bulk (automated upon receipt of viruses by the offending server), e-mail... thus UBE.

I know of no cases where a malware related DSN would be generated by our products, nevertheless, DSNs are not Unsolicited Bulk Email.

Generated virus "warnings" must not go to a known forged sender, or to a sender for which the forgery status is unknown. If you cannot *guarantee* that the address in MAIL FROM:<> is correct, and cannot reject at SMTP time, your only options are to quarantine, discard, or allow delivery. Do not send a DSN; do not pass Go; do not collect US$200.

Not all email is rejected within the SMTP session. You are changing requirements for recipients that scan incoming messages for malware. Fault them for returning content or not including a null bounce-address. No one can guarantee an email-address within the bounce-address is valid, furthermore a DSN could be desired even for cases where an authorization scheme fails. Why create corner cases?

There is always BATV to clean-up spoofed bounce-addresses in the meantime.

And other methods (DK, SPF, SID, choose your poison). However, if the server cannot verify that the MAIL FROM:<> is not forged with reasonable certainty, the server should not send a DSN, period. Otherwise, it's a direct contributor to the UBE problem.

DomainKeys and Sender-ID can not validate the bounce-address or the DSN. Even with an SPF failure, a DSN should still be sent, as SPF fails in several scenarios, and false positives are never 0%. BATV offers a unilateral option that can effectively discard spoofed bounce-addresses. When the AV software provides the DSN with a null bounce-address, BATV works as advertised.

-Doug

18

* Steven M. Bellovin:

A-V companies are in the business of analyzing viruses.

Many offer analysis services, but this is done upon special request,
and only if you pay extra.

They should *know* how a particular virus behaves.

You don't need to know what the virus does in order to detect it with
a file-based signature. Analysis stops as soon as detection is
possible with sufficient accuracy. Timebombs and other hidden
functionality go unnoticed (unless the malware is form a well-known
strain which has such features).

19

Riiiight.

Virus notifications aren't DSNs.

99% of the time, they're ads for the publisher of whatever anti-virus
filter is being used on the recipient's side.

20

Holding at the data phase does usually avoid the need for a DSN, but this
technique may require some added (less than elegant) operations depending upon
where the scan engine exists within the email stream.

Not my problem. I don't need or want, and should not be hammered with, virus "warnings" sent to forged addresses -- ever. They are unsolicited (I didn't request it, and definitely don't want it), bulk (automated upon receipt of viruses by the offending server), e- mail... thus UBE.

I know of no cases where a malware related DSN would be generated by our products, nevertheless, DSNs are not Unsolicited Bulk Email.

That's good Doug, and IMHO, your products should never generate them. However, I will disagree with you concerning the DSN being UBE. As a general rule, you are correct, DSN's != UBE. However, in the case of av systems (scanning engine and mta configurations) they can be. While I agree with you that the scanning engine(s) used by most of us, do not actually send reject notifications, the mechanisms that employ them, both commercial and open source, usually can, and do, unless configured not to. Some may see it as a violation of RFC to not return a DSN on failed delivery. Others, like myself see the need to not return a failure notice on virus / trojan infected email as it has become the norm that the sender information is forged. Especially those systems that contain the infected data along with the message. To many trojans / viri as of late, the DSN's that include the message (with infection) are being used as a repeater to further propogate the infection. Those that release these things are starting to depend on our mechanisms to help them spread. I, like others, prefer not to help them break the net from my little piece of it.