-----Original
Message-----
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt
Sent: Sunday, May 29, 2005 4:59 PM
To: [email protected]
Subject: Re: [Declude.Virus]
EXITSCANONVIRUS
Thanks! The grass is
cut and the friends are already on the way over with beer and stuff to burn :)
Matt
Darin Cox wrote:
Sounds good to
me. I tend to think of both virus and spam detection in the same breath,
since I think they're stronger together than separate... but you certainly have
a valid point about moving code to Junkmail...and it would seem more useful
there as well.
I haven't seen the
false positives you've seen with the Outlook Boundary Space Gap vulnerability,
but it may be due to a variation in customer base. I'll check the logs
and let you know what we've seen over a similar timeframe.
Happy Memorial Day
weekend! Don't forget to spend some time with the fam.
----- Original
Message -----
Sent: Sunday, May
29, 2005 5:35 PM
Subject: Re:
[Declude.Virus] EXITSCANONVIRUS
Darin,
My list was really only in respect to my feelings on Declude Virus and not
JunkMail. In this perspective of both however, maybe a modification where
#2 includes the potential of adding it as a test to JunkMail if it would be
beneficial, and a clarification on #3 like so:
1)
Active Vulnerabilities - Default to ON, and patch known
exceptions that could be triggered by standard E-mail clients. I would
expect that such things would stay in this category for at least a year
following a patch being released for the affected E-mail clients.
2) Inactive Vulnerabilities -
Default to OFF, don't necessarily patch issues when found (judgment
call). Add code to Declude JunkMail if useful for blocking spam.
I would expect that this category would include things that were between 1 and
3 years following a patch being issued for the affected E-mail clients.
3) Removal - Remove the code from
the Declude
Virus part of the executable. Depending on the
conditions related to the vulnerability; i.e. commonality in exploit, potential
for false positives, seriousness of flaw, etc., it would be prudent to remove
the code that detects such things after 2 or more years. Note that some
of these vulnerabilities have never been actively exploited by viruses.
Being conservative about leaving the code in for long periods I think is fine
because they would give people peace of mind and choice, but there is always
going to be a legitimate extent to which being conservative about things reach.
I think this reflects
what you have said, and in essence this is what I was indicating in the
paragraph that followed.
I would definitely like to see the Outlook CR Vulnerability added to Declude
JunkMail as a scoreable test since it does hit on a good deal of spam, but I
won't use it in Declude Virus since I can only chose to block or pass and it
has daily issues with false positives for my customer base.
Other present vulnerabilities might not justify keeping the code however.
The Outlook Boundary Space Gap vulnerability trapped a total of 8 messages that
weren't otherwise detected as viruses on my system in a two week period of
time, covering over 1 million scanned messages. Of these 8 messages, all
8 were legitimate personal E-mails generated by Microsoft's own E-mail
clients. I think we could agree that if this is the long-term trend, this
code would be best removed or fixed instead of being added to JunkMail.
Alternatively, if this is still a threat with this one vulnerability (I don't
know), then the detection should be fixed. The false positives were all
the result of an error in Declude where the following header was properly
'folded', but Declude seemingly experienced an error in de-folding the headers
which led it to believe that there were spaces within the boundary. The 4
spaces at the beginning of the second line in this case is part of proper
header folding
Content-Type:
multipart/alternative; boundary=
"----_=_NextPart_001_01C55D5F.F2B051DD"
This vulnerability is
designed to detect spaces or tabs within message boundaries, and apparently
could be exploited to package attachments which Outlook clients would
read. The above example is not an example of exploitable code.
RFC 2912 - http://www.faqs.org/rfcs/rfc2912.html
3.1 Whitespace and folding long headers
In some circumstances, media feature expressions can be very long.
According to "A Syntax for Describing Media Feature Sets" [1],
whitespace is allowed between lexical elements of a media feature
_expression_. Further, RFC822/MIME [4,5] allows folding of long
headers at points where whitespace appears to avoid line length
restrictions.
Therefore, it is recommended that whitespace is included as
permitted, especially in long media feature expressions, to
facilitate the folding of headers by agents that do not otherwise
understand the syntax of this field.
For this to have been the
vulnerability, the whitespace would have needed to have been within the quotes
that defined the boundary and not before it.
Matt
Darin Cox wrote:
I think most of us
always consider the "greater good" before making requests... and by
their nature, most requests from one person have benefit to many others.
I think the
recommendation you outlined below is fairly good...but again, I would not like
to see potentially valuable tests removed. Defaulting to off is good, but
removing doesn't make sense when there's value in the test. Other than an
occasional Partial vulnerability, I see no false positives with vulnerabilities
from our user base.
I do think your
point about moving the code from Virus over to Junkmail is a good one when it
is no longer an active vulnerability. I would just hate to see a
valuable test removed, and again, we see a decent amount of spam caught by
Virus that doesn't get caught by our Junkmail config.
Code can easily be
broken in moving from one place to another (Virus to Junkmail), so this may be
a maintenance problem that it is desirable to avoid.
However, deprecated vulnerabilities could potentially be more
valuable there for use in weighting or combo tests to identify particular
spammers and assist with detecting their payloads.
I think this all
falls under the "The more info we have about a message, the better we
can classify it" category. Indeed, one of the main reasons we
haven't migrated to SmarterMail is the unavailability of the CMDSPACE
test. We find much of the strength in Declude is due to the variety
of special tests Scott was able to come up with.
So, with the caveat
of not performing Item 3 in your list (Removal), it sounds very good to me.
It's nowhere near
#1 on my list either...just didn't want anything useful to disappear.
----- Original
Message -----
Sent: Sunday, May
29, 2005 4:22 PM
Subject: Re:
[Declude.Virus] EXITSCANONVIRUS
Darin,
I think there are many different ways to define "retire" in this
context.
Personally, I have already 'retired' the functionality on my system where I
feel that it appropriate, but when I share my opinions and recommendations, I
am often thinking of the greater good. I tend to not ask for things from
Declude that would not also be of benefit to a good number of it's users.
While having the switch alone might be good enough for the majority of us on these
lists, the majority of Declude's customers don't pay attention to the lists,
release notes, or many other things...they tend to run default configurations
with very little in the way of tweaks. These people are most in need of a
solution, though they probably mostly don't recognize the issue, and likewise
wouldn't recognize the solution. By Declude providing this functionality
and not working it into the overall approach for the best standard config and
practices, it really only serves the few of us that are paying very close
attention.
So in this perspective, the best global approach in my opinion would be to
establish a system for depricating such functionality. I would suggest
the following:
1)
Active Vulnerabilities - Default to ON, and patch known
exceptions that could be triggered by standard E-mail clients. I would
expect that such things would stay in this category for at least a year
following a patch being released for the affected E-mail clients.
2) Inactive Vulnerabilities -
Default to OFF, don't necessarily patch issues when found (judgment
call). I would expect that this category would include things that were
between 1 and 3 years following a patch being issued for the affected E-mail
clients.
3) Removal - Remove the code from
the executable. Depending on the conditions related to the vulnerability;
i.e. commonality in exploit, potential for false positives, seriousness of
flaw, etc., it would be prudent to remove the code that detects such things
after 2 or more years. Note that some of these vulnerabilities have never
been actively exploited by viruses. Being conservative about leaving the
code in for long periods I think is fine because they would give people peace
of mind and choice, but there is always going to be a legitimate extent to
which being conservative about things reach.
Regarding their use in blocking some spam, I personally would rather
Declude JunkMail tag such things, that way we could handle this as spam, as
well as the potential false positives, within the systems that we have built to
handle spam instead of the one built to handle viruses. Active
Vulnerabilities are a different story, but I wouldn't object to seeing code
added to BADHEADERS/SPAMHEADERS or another built-in test to show that something
failed a depricated check within the context of Declude JunkMail. Some of
these vulnerabilities are presently less than 90% accurate on my system in
judging between spam and ham, though the viruses associated with them might
well be deleted if they do exist and were detected by one of my scanners (I've
based this on a review of the spam folder and I delete viruses on my
system). The Outlook CR Vulnerability blocks the most spam, but it also
has the highest number of false positives by far. Web mail generated
messages from Comcast, Excite, 126.com/263.com (Chinese equivalent of Hotmail)
will all fail Outlook CR in Declude.
Does that sound reasonable? Would it provide for all of what you desire
in this respect? I do get that the folks at Declude do read this stuff
and they seem to be embracing our logic and popular opinion on the lists
lately, so I would guess that what you think does count for something.
Personally this isn't by far my #1 issue since I have already solved it with
other new functionality, but I think the process is just as if not more
important as the functionality to the product and the customer base as a whole.
Matt
--
=====================================================
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=====================================================
--
=====================================================
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=====================================================
