CVE-2014-0079: Unauthenticated remote crash in Zarafa

Am 28. Januar 2014 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 Passwort 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) (and if some certain build conditions are given) once the password 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 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.

Interestingly this remote Denial of Service flaw depends on either some certain compile-time flags or on some certain system libraries and headers because none of the officially available RPM or DEB packages provided by Zarafa is known to be affected. However all known community/self-built binaries, such as e.g. shipped by Fedora and Fedora EPEL, seem to be affected.

The build environment at Zarafa is not publically known thus a binary analysis (based on RHEL/CentOS 6) turned out these results: Binaries built by Zarafa contain the objects GLIBC_2.3.4 and GLIBCXX_3.4.11 while self-built binaries built on RHEL/CentOS 6 contain the objects GLIBC_2.4 and GLIBCXX_3.4.11. This leads to the conclusion (or assumption) that at least GLIBC < 2.4 is used in Zarafa's build environment while possible further impacts due to e.g. different build-time flags can not be excluded, too. Finally all Zarafa binary packages in Fedora and Fedora EPEL are affected where RHEL/CentOS 5 (with the oldest software) ships GLIBC 2.5 and Fedora Rawhide ships GLIBC 2.18.90 (currently as the latest).

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

<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><szUsername>robert</szUsername></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-0079 was assigned on February 12, 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.