CVE-2014-0079: Security Advisory für Zarafa

Ende Januar 2014 habe ich bei der Zarafa Collaboration Platform (ZCP), einer Open-Source-Groupware-Suite, die volle Kollaboration bei E-Mail, Kalender, Kontakten und Aufgaben ermöglicht und als Alternative zu Microsoft Exchange verwendet werden kann, neben CVE-2014-0037 noch eine weitere Schwachstelle entdeckt, welche sich aus der Ferne ausnutzen lässt. Nachfolgend unser Security Advisory mit weiteren Details:

Remote Denial of Service flaw at Zarafa Collaboration Platform
ETES GmbH Security Advisory; February 13, 2014

BACKGROUND

Zarafa, often also referred as Zarafa Collaboration Platform (ZCP), is an Open Source groupware suite which enables full collaboration of e-mail, calendaring, contacts and tasks. ZCP is used and well-known as a drop-in Microsoft Exchange replacement (origin: Zarafa Netherlands).

DESCRIPTION

Zarafa contains a flaw that could allow remote unauthenticated attackers to crash a Zarafa installation, preventing access to any other legitimate user of Zarafa. Please note that the remote Denial of Service flaw depends on either some compile-time flags or on some system libraries and headers. None of the official RPM/DEB packages provided by Zarafa is known to be affected. However all known community/self-build binaries, such as e.g. shipped by Fedora and Fedora EPEL, seem to be affected.

A binary analysis (based on RHEL/CentOS 6) turned out that official binaries built by Zarafa contain the objects GLIBC_2.3.4 and GLIBCXX_3.4.11 while self-build binaries built on RHEL/CentOS 6 contain the objects GLIBC_2.4 and GLIBCXX_3.4.11. However as RHEL/CentOS 5 already ships GLIBC 2.5 (and thus the object GLIBC_2.4 exists) the assumption is that Zarafa's build environment uses at least GLIBC < 2.4 while possible further impacts due to e.g. different build-time flags can not be excluded, too.

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

ANALYSIS

There is NO exploitation which would allow unauthenticated remote attackers to gain root access. An affected Zarafa installation is left with a crashed zarafa-server daemon (segmentation fault) while all other Zarafa related daemons are still running. The zarafa-server process provides the MAPI in SOAP service required by all other Zarafa related components as shown here: http://doc.zarafa.com/7.1/Administrator_Manual/en-US/html/_architecture.html

Every Zarafa installation (default or non-default) is affected except the official RPM/DEB packages provided by Zarafa are used or any legitimate remote usage of Zarafa's MAPI in SOAP is disabled via firewall or the Zarafa server configuration. The MAPI in SOAP connectivity is e.g. used by all Microsoft Outlook clients when not using IMAP but MAPI via the Zarafa Client Connector also known as Zarafa Windows Client.

REPRODUCABILITY

The reproducability is intentionally not described (at least for now) to really avoid as much Zarafa crash attacks of affected Zarafa installations as possible.

WORKAROUND

If not implemented so far, a firewall could be set up to restrict network access to either only trusted networks or by using deep packet inspection. However any firewalling may negatively affect Zarafa multi-server setups or other usecases of Zarafa such as e.g. legitimate remote users.

As there is currently no Zarafa release available solving this problem, the available patch suggestion should be applied at source code level. Afterwards a rebuild of Zarafa is of course necessary. Some downstreams like Fedora and Fedora EPEL already provide fixed binary RPM packages.

AFFECTED VERSIONS

All versions between Zarafa 6.20 Beta 1 (11098) and Zarafa 7.1.9 Final (44333).

FIXED VERSIONS

All versions after Zarafa 7.1.10 Beta 1 (44846).

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:

• CVE-2014-0079
• RHBZ #1059903
• OSS-SEC 2014/Q1/339
• SecurityFocus BID-65531

DISCLOSURE TIMELINE

• 2014-01-28: Initial discovery
• 2014-01-29: Reporter developed source code patch
• 2014-01-31: Initial vendor notification
• 2014-01-31: Reporter proposed source code patch to vendor
• 2014-02-01: Second vendor notification
• 2014-02-02: Initial vendor response and acknowledgement
• 2014-02-12: Red Hat Security Response Team assignes CVE name
• 2014-02-13: Coordinated public disclosure
• 2014-06-03: Vendor releases a fixed public final version

CREDIT

This vulnerability was discovered by Robert Scheck from ETES GmbH.

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

LEGAL NOTICES

Copyright © 2013-2014 ETES GmbH, referenced text(s) belongs to its owner(s).

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.