|
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.
Darin.
----- 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:
Hi Matt,
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.
Darin.
-----
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/
=====================================================
|
