CVE-2014-5448: Incorrect default permission in Zarafa

Am 15. August 2014 habe ich entdeckt, dass die standardmäßige Verzeichnisberechtigung von "/var/log/zarafa/" (Zarafa Collaboration Platform) nicht ausreichend restriktiv genug ist und damit die Protokoll-Dateien der Zarafa-Dienste von einem lokalen Angreifer gelesen werden können. Abhängig vom Log-Level der Dienste handelt es sich nur um z.B. Betreff, Absender, Empfänger und Message-ID von E-Mails, jedoch können auch Mitschnitte der Dienste bzw. Protokolle IMAP, POP3, CalDAV und iCal im Klartext einschließlich Kennwörtern enthalten sein. 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

All daemons/services of the Zarafa Collaboration Platform offer two different logging methods, either one logfile per service in /var/log/zarafa/ (which is the default) or alternatively sending the messages to syslog which adds it to the default maillog of the system. But the default permission of the log directory is world-readable, thus a local attacker can access all Zarafa logfiles read-only if the default logging configuration rather syslog is used.

CVSS v2 metrics

Analysis

There is no exploitation which would allow unauthenticated remote attackers to gain root access. However if an attacker gains access to the log files the leaked information (depending on the log level of the given Zarafa daemon/service) range from only e.g. subject, sender/recipient, message-id, SMTP queue ID of in- and outbound e-mails up to even a full cleartext protocol dump of IMAP, POP3, CalDAV and iCal as well (including possible credentials), thus further information leaks or attacks might be possible.

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:~ > id
uid=1000(robert) gid=100(users) groups=100(users) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
robert@tux:~ >

A system with the Zarafa Collaboration Platform is affected if the following command can be run as non-privileged system user without any permission error and the log directory itself has world readable permissions.

robert@tux:~ > ls -la /var/log/zarafa/
total 78988
drwxr-xr-x. 2 root root 4096 Sep 1 21:56 .
drwxr-xr-x. 9 root root 4096 Sep 1 21:52 ..
-rw-r--r--. 1 root root 2820 Sep 1 21:55 dagent.log
-rw-r--r--. 1 root root 41668415 Sep 1 21:55 gateway.log
-rw-r--r--. 1 root root 70411 Sep 1 21:55 ical.log
-rw-r--r--. 1 root root 12284 Sep 1 21:55 licensed.log
-rw-r--r--. 1 root root 58672 Sep 1 21:55 monitor.log
-rw-r--r--. 1 root root 19362581 Sep 1 21:55 search.log
-rw-r--r--. 1 root root 19503403 Sep 1 21:56 server.log
-rw-r--r--. 1 root root 180693 Sep 1 21:55 spooler.log
robert@tux:~ >

Workaround

Until a fixed version of the Zarafa Collaboration Platform is available (or for a system where a possible future update can not be applied for different reasons) the following command can be used to correct the wrong permission.

tux:~ # chmod 750 /var/log/zarafa/
tux:~ #

The command above is however only treated as a workaround because a possible non-fixed intermediate update of the Zarafa Collaboration Platform might revert this manually corrected permission again.

Solution

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

Affected versions

Fixed versions

CVE information

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

Disclosure timeline

Credit

This vulnerability 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.