Re: Sophie 3.05 encrypted file issues
Jay <[email protected]> Wed, 07 Dec 2005 13:38:48 +0800
| Newsgroups | gmane.comp.security.virus.vtools |
|---|---|
| Message-ID | <[email protected]> |
Hi All, I have been able to get Sophie to behave the way I believe it should by re-compiling sophie with the --enable-only-fatal-err flag. This now identifies encrypted archives as still being encrypted, but now returns 0 instead of -1. This post explains this behaviour: http://www.vanja.com/listarc/vtools/2003-November/001237.html This required no changes to amavis or sophie source code. Regards Jay Jay wrote: > Thanks for clarifying that process Scott. > > I agree with your point 1 in that it is not the best option to revert > back to 3.04 behaviour. > > As for point 2, I guess there are a couple of routes you could take here. > > One option could be to have sophie return a different code other than > -1 and have amavis be aware of this. > Amavis's behaviour could then potentially be controlled by a > configuration setting that would allow people to either pass the message > or drop the message if it contained a password protected archive. > > This would require coordination from both the Sophie team and the > Amavis team. > > Having amavis ignore -1 would also solve this issue, but -1 is also > used for other critical errors I believe in which case ignoring them > could introduce new issues. > From what I have seen of Amavis, the config file contains regex that > allows it to determine whether a file was virus infected or not, is > this the case? > > If so, if sophie was to return a different code, would it be as simple > as modifying this regex to pass the different code? > > Regards > Jay > > [email protected] wrote: > >> I just had a look at the amavis code. It instructs Sophie to scan a >> directory, not a single file. In past versions of Sophie, scanning a >> directory would ignore errors and always return clean (0) unless a >> file in >> the directory was infected. Since amavis scans a directory, it seems it >> was always ignoring error files and silently passing them through. In >> 3.05, sophie_scandir was changed to also report errors, which is what >> you >> are encountering below. Scanning a file (sophie_scanfile) has always >> reported errors via the -1 return code. sophos_scandir was changed so >> that's its behaviour matched that of sophie_scanfile. >> >> So, I guess the options are: >> >> 1) Should Sophie be reverted back to 3.04 behaviour to ignore errors >> when >> scanning a directory? >> I personally think no, since this is rather unsafe >> >> 2) Should amavis be changed to handle -1 return codes by Sophie >> differently. Since amavis only checks the number return code, there >> is no >> current way to say things like "allow password protected zips but deny >> corrupt files" because Sophie returns -1 in both causes. I guess you >> are >> left with the choice of allowing all error files or denying all error >> files. >> Modifying amavis to ignore -1 error codes from Sophie is only a >> matter of >> commenting out a couple lines. >> >> Any thoughts? >> >> Regards, >> Scott. >> >> >> [email protected] wrote on 12/06/2005 03:02:32 PM: >> >> >> >>> Hi All, >>> >>> I have just upgraded my mailserver to Sophie 3.05 and >>> libsavi.so.3.2.07.119 using amavisd-new-2.3.1 >>> >>> NOTICE : Sophie configuration file not specified - falling >>> back to defaults >>> NOTICE : Using Sophie configuration file '/etc/sophie.cfg' >>> NOTICE : Setting configuration options - please wait... >>> NOTICE : Configuration options set >>> Sophos engine : Sophos engine version 2.32 >>> Sophie IDE : Sophos IDE version 4.00 (detects 114935 viruses) >>> SAVI config : /etc/sophie.savi >>> Max processes : 20 >>> Socket path : /var/run/sophie >>> Umask : 7 >>> PID file : /var/run/sophie.pid >>> Timeout : 300 seconds >>> Running as user : amavis >>> Socket group : amavis >>> Logname : sophie >>> Log facility : 16 (mail) >>> Log priority : 5 (notice) >>> Error strings? : yes >>> Timestamps? : no >>> Show virus name? : yes >>> Callbacks? : yes >>> limit_classif : 10 >>> limit_nextfile : 10000 >>> limit_decompr : 1000 >>> socket_check : yes >>> Sophie version : 3.05 >>> NOTICE : pSAVI cleaned up and released/terminated >>> >>> >>> When someone sends through an email with a password protected zip file >>> the following is shown in the maillog: >>> >>> Dec 6 04:28:12 xxxxxxxx sophie[32719]: Sophie child has timed-out (no >>> data received in 300 seconds) - process killed >>> Dec 6 04:28:12 xxxxxxxx sophie[1036]: WARNING : Error: File >>> was encrypted >>> Dec 6 04:28:12 xxxxxxxx amavis[508]: (00508-01) ask_av (Sophie) FAILED >>> - unexpected result: -1:Error: File was encrypted >>> Dec 6 04:28:12 xxxxxxxx amavis[508]: (00508-01) WARN: all primary >>> virus >>> scanners failed, considering backups >>> Dec 6 04:28:12 xxxxxxxx amavis[508]: (00508-01) TROUBLE in check_mail: >>> virus_scan FAILED: virus_scan: ALL VIRUS SCANNERS FAILED: >>> Dec 6 04:28:12 xxxxxxxx amavis[508]: (00508-01) PRESERVING EVIDENCE in >>> /mnt/tmpfs/amavis/amavis-20051206T042306-00508 >>> >>> The message is subsequently not delivered and stored in >>> >> >> /mnt/tmpfs/amavis/ >> >> >>> This is very much different behaviour than previous versions of Sophie >>> where a password protected zip would not be scanned but would still be >>> delivered. >>> >>> I think it maybe due to this change listed in the Sophie 3.05 >>> changelog: >>> - Bug fix for sophie_scandir problem. Sophie would not report >>> corrupt, password protected, etc files when performing directory >>> scans. It has been changed to return the "worst" result now. If >>> there is an infected file with a scanned directory, the >>> infected return code (1) is returned. If, however, the directory >>> (and all sub-directories) are clean, but there is at least one >>> error (corrupt, password protected, etc) file, Sophie will return >>> the error return code (-1). Only if all files are clean and >>> error free will the OK (0) code be returned. >>> >>> This change appears to indicate that "-1" will be returned when >>> sophie_scandir is called, but according to the output in the maillog it >>> is also being returned when a single file sent from amavis is being >>> scanned and amavis does not know what "-1" means? >>> Is this intentional behaviour, or is this an oversight with this >>> change? >>> >>> I have managed to work around this for the time being by enabling sweep >>> as a fallback scanner in amavis, as sweep does not return an error with >>> password protected zips. This isn't ideal and I was hoping someone here >>> could shed some light on this. >>> >>> Thanks for your time >>> >>> Regards >>> Jay >>> >>> _______________________________________________ >>> vtools mailing list >>> [email protected] >>> http://www.vanja.com/list/listinfo.cgi/vtools >>> >> >> >> _______________________________________________ >> vtools mailing list >> [email protected] >> http://www.vanja.com/list/listinfo.cgi/vtools >> >> > > _______________________________________________ > vtools mailing list > [email protected] > http://www.vanja.com/list/listinfo.cgi/vtools