Corrupt or encrypted items quarantined by SAVDI when option set to disabled

When using SAVDI in combination with EMC Isilon, files resulting in corrupt, error or encrypted results are quarantined even when the option to block them is not enabled.

This is caused by SAVDI’s use of the ICAP 204 and 200 ICAP return codes.

This article describes the steps to resolve this issue.

The following sections are covered:

Applies to the following Sophos products and versions

SAV Dynamic Interface 2.5.0

  1. Upgrade to SAVDI version 2.5.0
  2. Add the following line to the savdid.conf file in the scanprotocol section:

    useclean204: YES

    Note: This should result in a scanprotocol section similar to the below:

    scanprotocol {

    type: ICAP

    useclean204: YES

    }

    Note: To make use of this feature please set either block-error, block-encrypted or block-corrupt to NO

    It will only affect the block setting(s) that is(/are) set to NO.

  3. Restart the SAVDI service

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable to us to ensure that we continually strive to give our customers the best information possible.

Related:

  • No Related Posts

Disabled SMB1 protocol on Windows Update Server leads to update failure on Linux Server endpoint

Currently if the SMB1 protocol has been disabled on the update server* SAV Linux Servers updating from this machine will fail to update. This is because the Samba version used in the current version of Sophos Anti-Virus for Linux relies on the SMB1 protocol when updating from the Windows Server.

The following error will be seen in the syslog/messages file:

2017-02-20 08:12:33: update.failed Failed to update from primary update source. Redirecting to secondary update source.

This is resolved in the just released version of Sophos Anti-Virus for Linux (9.13.2) where the Samba libraries have been updated (version 4.6.1) for compatibility with later SMB versions.

*to check the version enter the command Get-SmbServerConfiguration in a Power Shell Window.

Applies to the following Sophos product(s) and version(s)

Sophos Anti-Virus for Linux

What To Do

Current workarounds prior to product update to this release:

One option would be to re-enable SMB1 on the Windows Server until the next release of Sophos Anti-Virus for Linux.

If SMB 1 has already been disabled on the Windows Update Server and if this cannot be re-enabled until the next SAV Linux release there are the following workarounds.

1 – Set the Secondary Server in the SEC updating policy to update directly from Sophos using your Sophos credentials. An update from the Primary location (SEC CID share) will be attempted and will fail and the update will the go directly to Sophos on-line.

This means updating may take longer and the logs will contain errors that the attempted update from the Primary Server failed.

2 – Create an IIS Web CID (See KBAs 38238, 64787) and use this as the Primary Update location.

Related:

PCTI.DBVB.dll detected as Mal/Generic-S

On 18th May 2017 we received a small number of reports of an incorrect detection on a DLL named PCTI.DBVB.dll which forms part of an application called Docman. We updated our detection rules for this file as of 10:22 UTC on the 18th May 2017, and are no longer blocking this DLL. However customers using this software before this time, who had automatic cleanup enabled, may notice errors during the use of it.

If you are experiencing issues as a result of this detection please contact Sophos Technical Support immediately for further advice, we can provide you with a script which should restore the DLL and return Docman to normal operation.

We will continue to update this article as further information becomes available.

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable to us to ensure that we continually strive to give our customers the best information possible.

Related:

Advisory: Recommended steps for the Poodle vulnerability in SMTP Proxy on the Sophos UTM

This article provides the recommended steps for the Poodle vulnerability in SMTP Proxy on the Sophos UTM.

Applies to the following Sophos product(s) and version(s)

Sophos UTM

Advisory: Recommended steps for the Poodle vulnerability in SMTP Proxy on the Sophos UTM

What is the vulnerability?

For details about this vulnerability, see https://nakedsecurity.sophos.com/2014/10/16/poodle-attack-takes-bytes-out-of-your-data-heres-what-to-do/

Recommended steps for SMTP Proxy

Disable SSLv3 for SMTP and turn TLSv1.2 back on:

For versions up to 9.209 and 9.300 until 9.303 of the UTM

  • Navigate to /var/chroot-smtp/etc/
  • Open the exim.conf with vi: vi exim.conf
  • Change(or add if missing) the line openssl_options to: openssl_options = +no_sslv3

    at the end of the section #TLS

  • Note: Make sure that the values for tls_require_ciphers looks as follows before you save your changes:

    RC4+RSA:HIGH:!MD5:!ADH:!SSLv2

  • Save your changes and close the editor: :wq
  • Now restart the smtpd service by executing /var/mdw/scripts/smtp restart

For version 9.210 of the UTM

  • Navigate to /var/chroot-smtp/etc/
  • Open the exim.conf with vi: vi exim.conf
  • Change the values for tls_require_ciphers looks as follows(remove the “:!SSLv3”):

    RC4+RSA:HIGH:!MD5:!ADH:!SSLv2

  • Add the following line: openssl_options = +no_sslv3

    at the end of the section #TLS
  • Save your changes and close the editor: :wq
  • Now restart the smtpd service by executing /var/mdw/scripts/smtp restart

After I have considered the recommended steps my mailserver isn´t able to communicate with the Sophos UTM anymore – What should I do?

Some mailserver do not support TLS 1.2. In this case proceed as follows:

  • Navigate to /var/chroot-smtp/etc/
  • Open the exim.conf with vi: vi exim.conf
  • Change the line openssl_options to: openssl_options = +no_sslv3 +no_tlsv1_2
  • Save your changes and close the editor: :wq
  • Now restart the smtpd service by executing /var/mdw/scripts/smtp restart

Some mailservers only support SSLv3. In this case you would need to reactive the support for SSLv3(vulnerable in this case) as follows:

  • Navigate to /var/chroot-smtp/etc/
  • Open the exim.conf with vi: vi exim.conf
  • Remove the line openssl_options = +no_sslv3
  • Save your changes and close the editor: :wq
  • Now restart the smtpd service by executing /var/mdw/scripts/smtp restart

Related:

Advisory: OpenSSL Security Advisory [05 Jun 2014]

On June 5th 2014 the OpenSSL Project published an advisory listing seven security defects in their software along with an update to fix them.

Certain Sophos products use the OpenSSL cryptography libraries and hence this article provides information on the issue in relation to our products.

Important: We are fully investigating this issue and will update this article to provide further information when available.

Applies to the following Sophos product(s) and version(s)

Sophos UTM

PureMessage for Unix

Sophos Email Appliance

Sophos Web Appliance

Sophos UTM Manager

Sophos Cloud

What are the OpenSSL defects?

See the table below for a list of CVE numbers and brief description.

CVE reference† Description
CVE-2014-0224 SSL/TLS MITM vulnerability
CVE-2014-0221 DTLS recursion flaw
CVE-2014-0195 DTLS invalid fragment vulnerability
CVE-2014-0198 SSL_MODE_RELEASE_BUFFERS NULL pointer dereference
CVE-2010-5298 SSL_MODE_RELEASE_BUFFERS session injection or denial of service
CVE-2014-3470 Anonymous ECDH denial of service
CVE-2014-0076 Fix for the attack described in the paper “Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack”

†CVE provides a standardized reference number and information on public security vulnerabilities and exposures. For more information see the cve.mitre.org website.

The list of defects as published by the OpenSSL Project can be found at the following link:

What versions of OpenSSL are affected?

Until the latest software release on June 5th all versions of OpenSSL in client applications were vulnerable . The flaw goes back to the origin of the code in 1998. Only versions 1.0.1 and higher of the server are vulnerable.

For more information see our naked security blog article:

Have any of the OpenSSL defects been exploited so far?

No.

Is this the same as ‘heartbleed’?

No. Heartbleed (CVE-2014-0160) was disclosed by the OpenSSL Project on April 7th 2014 and was an earlier software defect.

What Sophos products are affected?

The table below lists the affected Sophos products, associated CVE number, and further information.

Important: When our development teams complete their investigation all affected products and resolutions will be listed. If a product is not listed in the table below it is not affected in any way.

Product affected Associated CVE Further information
Sophos UTM v8.3

Sophos UTM v9.1

Sophos UTM v9.2
CVE-2014-0224

The affected versions will be fixed in the respective versions below:

v8.312(released – Please check KBA 121112 for update instructions)

v9.113 (released – Please check KBA 121112 for update instructions)

v9.203 (released – Please check KBA 121112 for update instructions)

Sophos UTM Manager v4.1 and 4.2 CVE-2014-0224

Patched in version 4.107(released):

Up2date link

MD5SUM: be4f0d72e7266882bb3cd63cdc92bb90

File size ~198MB

Patched in version 4.201(released):

Up2date link

MD5SUM: 42ddbb8f7eb30cc98a23f2f88b0e52fe

File size ~50MB

Sophos Web Appliance v3.9.x.x CVE-2014-0224 Patch in v3.9.0.2 (expected June 11th, 2014)
Sophos Email Appliance v3.7.x.x CVE-2014-0224 Patch in v3.8.0.0 (expected week commencing June 23rd 2014)
PureMessage for UNIX v6 CVE-2014-0224 Patch expected June 25th June 2014
Sophos Cloud CVE-2014-0224 Patched 17th June 2014

I have a further question, what should I do?

If something in the article is not clear leave a comment in the form below. Otherwise post your question to our community:

Related: