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