Re: [Declude.Virus] EXITSCANONVIRUS

[Matt]

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 Darin Cox wrote: Matt,   Point taken that it may no longer be a vulnerability.  So, call it something different, maybe just another type of spam test, but don't take it away.  They still have value as tests.  As I stated earlier, we see spam held by the vulnerability tests that were not detected by spam tests.   If the vulnerability/test can be disabled so it doesn't add any processing time to your config, why argue that it should be taken away from someone else who still has a use for it?   Darin.     ----- Original Message ----- From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 2:06 PM Subject: Re: [Declude.Virus] EXITSCANONVIRUS Darin, A vulnerability is only a vulnerability if there is an application vulnerable to it.  Viruses also won't ever achieve 'critical mass' and therefore won't succeed in the wild if they rely on exploiting a vulnerability that no longer exists.  Given that some of these vulnerabilities have been patched for more than two years, it is unlikely that a mass-mailing virus would attempt to exploit one of them, and if they relied on one of these methods that was long since patched, they could end up hurting their chances of success since their attachments wouldn't be seen by the E-mail clients receiving them (it would be better just to attach it normally and would make no sense to try to exploit the old vulnerability). Many of the vulnerability checks in Declude were the result of flaws in Outlook and Outlook Express.  There were mostly ways to package in attachments in E-mails so that error correction in the clients would display or even execute the attachments, but the deMIMEing engines associated with E-mail virus scanners might not recognize them as attachments and therefore might not even attempt to scan the attachments.  The shortcoming to many of Declude's vulnerability checks is that they might only check for the presence of the precursor or non-standard (but sometimes compliant) construction, and not the presence of the exploit (such as an attachment buried in the headers).  So in essence all this is tagging is construction, and there are flaws in many of the current detection methods that can tag legitimate E-mail. This didn't become much of an issue for me until the number of addresses and domains expanded to the point where most flaws in the detection, or otherwise error prone mailers of legitimate E-mail were tripping these things in measurable numbers every single day.  For servers with single domains or fewer addresses, this is probably much less of an issue, but the false positives would be more likely to go undetected. My opinion is that every vulnerability has a lifespan, and eventually should be retired if there is any chance of it causing a false positive, or even regardless.  One example would be the "Object Data Vulnerability".  This was discovered by eEye in the April of 2003 and patched by Microsoft on October 3, 2003.  Two fairly unsuccessful Bagle variants exploited this vulnerability in April of 2004 and Declude added this to their list of vulnerabilities in response.  While other viruses might have attempted to exploit this vulnerability, it would not be successful given the year and a half since the patch...it wouldn't be successful enough to achieve critical mass.  On the flip side of this, I have found that Outlook can trip this vulnerability in Declude under certain circumstances, though I'm not sure what exactly they are, and the only solutions would be to fix the detection, turn it off, or retire it.  I have almost zero concern about this causing me any issues by not detecting it at this point.    http://www.eeye.com/html/Research/Advisories/AD20030820.html    http://www.microsoft.com/technet/security/bulletin/MS03-040.mspx There are similar conditions for other vulnerabilities as well.  It was good to have them at the time, but now they are more trouble that their worth in my opinion. Matt Darin Cox wrote: I would hope existing vulnerability checks would not be retired, since there are already flags to decide whether or not to check for particular ones.  We catch a bit of spam in the virus queue with these checks that is not otherwise caught, especially some that someone else (Andrew?) mentioned getting rid of.   Unless there is 100% probability that no one will use the functionality any longer, please add flags to turn it off instead of removing it completely.  That way those that still prefer it can still use it. Darin.     ----- Original Message ----- From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 1:23 AM Subject: Re: [Declude.Virus] EXITSCANONVIRUS John, I don't think that the behavior displayed in your logs was entirely purposeful.  Declude tagged it with a vulnerability and then it ran your first virus scanner and found no virus, and then apparently it decided not to run the last two virus scanners.  This of course is only interim functionality and I would imagine that they would be open to reports of unexpected behavior as well as tweaks for more optimal behavior. I believe that the intended functionality for EXITSCANONVIRUS ON would be to ignore the vulnerabilities and only skip further virus scanning when a prior virus scanner reports an exit code that you have configured to mark it as a virus.  This seems consistent with what you are saying it should be. In an older thread regarding some bugs with F-Prot and other related things, Andrew also suggested separate functionality that would skip virus scanning when a vulnerability was found since that would be enough to block it on most systems.  At that time I suggested that this was not necessarily a good idea, but I made a mistake. For my system, and many others running BANCRVIRUSES ON, it might be an even bigger CPU savings to skip all virus scanners when a vulnerability is detected.  The only downside to this is that you will fill up your virus directory when using such a switch unless you are using another new directive, DELETEVULNERABILITIES ON.  Naturally skipping virus scanning for vulnerabilities would be optional and not the default setting, and so would be deleting vulnerabilities.  I would be in favor of seeing something like EXITSCANONVULNERABILITY added to Declude. Note that there are many issues with the current set of vulnerability checks that Declude does, and it would help to address these at the same time.  We do have a switch to turn most of this off, but I get the impression that they are aware of the issues and are considering or may have decided to approach vulnerabilities differently, or possibly retiring some where appropriate.  Deleting messages that fail vulnerability checks but aren't tagged as viruses should only really be done if you can rely on the vulnerability checks to be accurate. Matt John Tolmachoff (Lists) wrote: It appears to be stopping when it finds a vulnerability and does not get scanned for virus. John T eServices For You -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Colbeck, Andrew Sent: Saturday, May 28, 2005 5:58 PM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS ... that's reasonable, John. How does it work up to now? If a vulnerability and a virus are detected, which gets reported? Andrew 8) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Tolmachoff (Lists) Sent: Saturday, May 28, 2005 5:17 PM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS I agree with Darrell. If it contains a virus, I want it to be marked as a virus. If it does not contain a virus, then if it contains a vulnerability or banned extension then mark as such. An example is that some Sober viruses also contain vulnerability. Well, I want it labeled as a virus not vulnerability. John T eServices For You -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Darrell ([EMAIL PROTECTED]) Sent: Saturday, May 28, 2005 10:10 AM To: Declude.Virus@declude.com Subject: Re: [Declude.Virus] EXITSCANONVIRUS My thoughts are this - a virus is a virus and a vulnerability is a vulnerability. My expectation is that if a virus is detected than the other scanners will not be called. However, if a vulnerability is detected the scanners will execute until such time a "virus" is found. Maybe two switches - EXITSCANONVULNERABILITY... However, on the grander scale of things if nothing changed on this I would still use EXITSCANONVIRUS as long as it observes the various delivery options on vulnerabilities. Darrell ------------------------------------------- invURIBL - Intelligent URI Filtering. Stops 85%+ SPAM with the default configuration. Download a copy today - http://www.invariantsystems.com ----- Original Message ----- From: "Colbeck, Andrew" <[EMAIL PROTECTED]> To: <Declude.Virus@declude.com> Sent: Saturday, May 28, 2005 12:49 PM Subject: RE: [Declude.Virus] EXITSCANONVIRUS John, can you expand on that? In my implementation, there is no difference in message treatment if a vulnerability or virus is detected. Therefore, I am happy to stop the virus scanning if a vulnerability is detected. That is, as long as ALLOWVULNERABILITIESFROM is still respected. Of course, I've already found that these two had too many false positives for the safety they afford, so I've turned them off: BANPARTIAL OFF BANCRVIRUSES OFF which leaves me with BANCLSID ON which has never been triggered. Andrew 8) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Tolmachoff (Lists) Sent: Saturday, May 28, 2005 12:34 AM To: Declude.Virus@declude.com Subject: RE: [Declude.Virus] EXITSCANONVIRUS Well, here is an example of what I was hoping not to see. 05/27/2005 23:35:14 Q112105DF00002AB2 Vulnerability flags = 0 05/27/2005 23:35:14 Q112105DF00002AB2 Outlook 'CR' vulnerability [Subject: H] in line 15 05/27/2005 23:35:15 Q112105DF00002AB2 Virus scanner 1 reports exit code of 0 05/27/2005 23:35:15 Q112105DF00002AB2 File(s) are INFECTED [[Outlook 'CR' Vulnerability]: 0] 05/27/2005 23:35:36 Q112105DF00002AB2 Scanned: CONTAINS A VIRUS 05/27/2005 23:35:36 Q112105DF00002AB2 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] [incoming from x.x.x.x] 05/27/2005 23:35:36 Q112105DF00002AB2 Subject: How is Rebecca doing? In this case, the subject line is the last line for the message in the Declude Virus log in HIGH and it apparently shows that scanners 2 & 3 were not called. If it finds a vulnerability, it still should fire the scanners to see if one of them finds an actual virus. John T eServices For You -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of David Franco-Rocha [ Declude ] Sent: Friday, May 27, 2005 7:21 AM To: Declude.Virus@declude.com Subject: Re: [Declude.Virus] EXITSCANONVIRUS John, There is a processing loop wherein all the scanners are called in succession. It is independent of vulnerability checking. This directive merely tells Declude to break out of the external virus scanner execution loop. If you use this directive to exit the scanning loop on virus detection and (1) you have 5 scanners listed in your cfg file and (2) a virus is detected by the first scanner listed, then the effect is exactly the same in processing as if you had a single scanner listed and a virus were detected by that single scanner. David Franco-Rocha Declude Technical Support ----- Original Message ----- From: "John Tolmachoff (Lists)" <[EMAIL PROTECTED]> To: <Declude.Virus@declude.com> Sent: Friday, May 27, 2005 2:50 AM Subject: [Declude.Virus] EXITSCANONVIRUS A question about this new feature. Am I correct in thinking that as soon as a scanner reports a virus, the next scanner(s) in line will not be called and the message will be processed accordingly, and that it will not be affected by Declude first finding a banned attachment before having it scanned by a scanner? John T eServices For You --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus". The archives can be found at http://www.mail-archive.com. -- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ ===================================================== -- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ ===================================================== -- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =====================================================