RSC-SA-2014-0011: SSLv3 limit in Zarafa Outlook Client

Am 2. April 2014 habe ich entdeckt, dass der proprietäre Zarafa Outlook Client, der für die MAPI-basierte Anbindung von Microsoft Outlook an Zarafa verwendet wird, ausschließlich SSLv3-Verbindungen unterstützt. Die Tests dazu resultierten aus meinem Patch für den Zarafa-Server um SSL-/TLS-Einstellungen wie Protokoll-Version und Cipher Suite konfigurierbar zu machen. Aufgrund des nicht offenliegenden Quellcodes handelt es sich lediglich um Testergebnisse. Nachfolgend das Security Advisory in englischer Sprache:

Background

Zarafa is a leading European provider of open source groupware and collaboration software. The core product is the Zarafa Collaboration Platform (ZCP), an European open and compatible groupware platform that can be used as a drop-in Microsoft Exchange replacement for e-mail, calendaring, collaboration and tasks (origin: Zarafa company profile).

Description

For accessing e-mails, calendars, contacts and tasks of the groupware platform via Microsoft Outlook, Zarafa provides the proprietary Zarafa Outlook Client, also known as Zarafa Windows Client, Zarafa Outlook Plugin or Zarafa Client Connector. The Zarafa Outlook Client connects via MAPI in SOAP over HTTP(S) to the configured zarafa-server daemon/service. But when choosing (instead of default cleartext connection over HTTP) the encrypted HTTPS e.g. via TCP port 237, the encrypted connection between the client and the zarafa-server daemon/service is limited to SSLv3 due to the Zarafa Outlook Client.

Analysis

There is no exploitation which would allow unauthenticated remote attackers to gain root access. However, given that it has not yet been clarified whether POODLE is applicable to SSLv3 connections which are not being used for website content (and thus without e.g. HTTP session cookies), the usage of an SSLv3 connection is only or at least a risk. Additionally, the Federal Office for Information Security (BSI) of the Federal Republic of Germany also specifies in their document TR-02102-2 that SSLv3 is not to be used anymore.

While even the file README.win32 as part of e.g. zcp-win32-7.1.11.tar.gz still refers to openssl-win32-0.9.8k.zip and thus to OpenSSL 0.9.8k (released 2009-03-25), the Zarafa Outlook Client bundles OpenSSL 1.0.1c (released 2012-05-10) since version 7.1.2, and since Zarafa Outlook Client version 7.2.0 the OpenSSL 1.0.1j (released 2014-10-15) is bundled. The verification is e.g. possible under Linux using 7za x -so zarafaclient-7.1.11-47521.msi zarafa6client32.dll 2> /dev/null | strings | grep OpenSSL on the command line.

Reproducability

The following commands are only made public to demonstrate how to figure out whether the currently used Zarafa Outlook Client is limited to SSLv3 or not. In the very first beginning a SSL certificate is required. Given that a self-signed SSL certificate is sufficient it can be created by using openssl on the command line:

tux:~ # echo -e "--\n--\n--\n--\n\n\n\n" | openssl req -x509 -sha256 -nodes -newkey rsa:4096 -keyout key.pem -out cert.pem -days 7 2> /dev/null
tux:~ # ls -l cert.pem key.pem
total 8
-rw-r--r--. 1 root root 1874 Jan 31 16:00 cert.pem
-rw-r--r--. 1 root root 3272 Jan 31 16:00 key.pem
tux:~ #

This SSL certificate is going to be used in the following stunnel configuration file. It is important to keep in mind that this stunnel configuration file does not replace the need to have a fully working Zarafa server setup listening at least on 127.0.0.1 on TCP port 236.

tux:~ # cat sslv3.conf
cert = cert.pem
key = key.pem
foreground = yes
fips = no
sslVersion = SSLv3
debug = 3

[238]
accept = 0.0.0.0:238
connect = 127.0.0.1:236
tux:~ #

For the next step a Microsoft Outlook and the Zarafa Outlook Client are required; an existing Microsoft Outlook profile can be simply either reconfigured to use an encrypted connection and TCP port 238 or a new profile could be created as well. Starting stunnel leads to the following output on the command line:

tux:~ # stunnel sslv3.conf
2015.01.31 16:02:43 LOG3[11806:140486172817152]: SSL_accept: 14094412: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
2015.01.31 16:02:43 LOG3[11806:140486172747520]: SSL_accept: 14094412: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
2015.01.31 16:02:57 LOG3[11806:140486173304576]: SSL_read: Connection reset by peer (104)
2015.01.31 16:02:57 LOG3[11806:140486173234944]: SSL_read: Connection reset by peer (104)
2015.01.31 16:02:57 LOG3[11806:140486173026048]: SSL_read: Connection reset by peer (104)
2015.01.31 16:02:57 LOG3[11806:140486172886784]: SSL_read: Connection reset by peer (104)
2015.01.31 16:02:57 LOG3[11806:140486173165312]: SSL_read: Connection reset by peer (104)
2015.01.31 16:02:57 LOG3[11806:140486173095680]: SSL_read: Connection reset by peer (104)
^C
2015.01.31 16:02:59 LOG3[11806:140486173308864]: Received signal 2; terminating
tux:~ #

The start of Microsoft Outlook should succeed, the first two log lines are caused by the self-signed SSL certificate, the others are caused when closing Microsoft Outlook. Finally press Ctrl + C to stop stunnel as well.

Previous steps were related to SSLv3 only. The following steps are the same but with TLSv1.0 instead. The same SSL certificate is going to be used in the following stunnel configuration file. It is important to keep in mind that this stunnel configuration file does not replace the need to have a fully working Zarafa server setup listening at least on 127.0.0.1 on TCP port 236.

tux:~ # cat tlsv1.conf
cert = cert.pem
key = key.pem
foreground = yes
fips = no
sslVersion = TLSv1
debug = 3

[238]
accept = 0.0.0.0:238
connect = 127.0.0.1:236
tux:~ #

For the next step a Microsoft Outlook and the Zarafa Outlook Client are required again; the previously used Microsoft Outlook profile can be simply either reused, another profile could be reconfigured to use an encrypted connection and TCP port 238 or a new profile could be created as well. Starting stunnel leads to the following output on the command line:

tux:~ # stunnel tlsv1.conf
2015.01.31 16:04:35 LOG3[11866:140180333680384]: SSL_accept: 1408A10B: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
2015.01.31 16:04:35 LOG3[11866:140180333680384]: SSL_accept: 1408A10B: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
2015.01.31 16:04:35 LOG3[11866:140180333680384]: SSL_accept: 1408A10B: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
2015.01.31 16:04:35 LOG3[11866:140180333680384]: SSL_accept: 1408A10B: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
2015.01.31 16:04:35 LOG3[11866:140180333680384]: SSL_accept: 1408A10B: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
2015.01.31 16:04:35 LOG3[11866:140180333680384]: SSL_accept: 1408A10B: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
2015.01.31 16:04:35 LOG3[11866:140180333680384]: SSL_accept: 1408A10B: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
2015.01.31 16:04:35 LOG3[11866:140180333680384]: SSL_accept: 1408A10B: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
2015.01.31 16:04:35 LOG3[11866:140180333680384]: SSL_accept: 1408A10B: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
2015.01.31 16:04:35 LOG3[11866:140180333680384]: SSL_accept: 1408A10B: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number
^C
2015.01.31 16:04:43 LOG3[11866:140180333684672]: Received signal 2; terminating
tux:~ #

Screenshot of error when using SSLv3-only Zarafa Outlook Client without SSLv3 with Microsoft Outlook 2010The start of Microsoft Outlook fails with the error message like "Cannot open your default email folders. The information store could not be opened." or "Ihre Standard-E-Mail-Ordner können nicht geöffnet werden. Der Informationsspeicher steht zurzeit nicht zur Verfügung.". The exact error message depends on the version and language of Microsoft Outlook. Finally press Ctrl + C to stop stunnel as well.

Workaround

Given this issue is a design flaw the only workaround is to wrap the SSLv3 connection of the Zarafa Outlook Client by something like VPN (or another tunneling technology) where the encryption is ensured by the wrapping technology. However such a workaround might not provide the same end user comfort.

Solution

As there are fixed releases of the Zarafa Outlook Client available, an update is highly recommented over any workaround.

The flaw was initially technically solved by replacing the SSLv3-only requirement by a TLSv1.0-only requirement, thus the Zarafa Outlook Client <= 7.2.0 Beta 1 (47518) supports TLSv1.0, but does not support TLSv1.1 or TLSv1.2 and might be subjected to further (similar) issues in the future and especially in case of security related issues with TLSv1.0. The newer Zarafa Outlook Client >= 7.2.0 Beta 2 (47829) however supports TLSv1.0, TLSv1.1 and TLSv1.2.

Affected versions

Fixed versions

CVE information

No MITRE Corporation Common Vulnerabilities and Exposures (CVE) number has been assigned. Currently, the following other identifications are known for this issue:

Disclosure timeline

Credit

Zarafa Outlook Client being affected by this risk was discovered, analyzed and reported by Robert Scheck.

Legal notices

Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an as is condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.