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