I discovered (aside bug #1056767) another flaw in Zarafa that could allow a remote unauthenticated attacker to crash the zarafa-server daemon, preventing access to any other legitimate Zarafa users.

The issue affects all Zarafa versions from at least Zarafa 6.20.0 (maybe even from at least Zarafa 5.00) up to (including) Zarafa 7.1.8 final. Please note that I was not able to crash the zarafa-server daemon using official upstream Zarafa binary packages just all community builds from the source code such as shipped in Fedora. This different behaviour might be caused that upstream uses different built-time flags or other system libraries and headers.

Once the zarafa-server process crashes with a backtrace (and even all other Zarafa related daemons are still running) there is no Zarafa functionality till zarafa-server daemon is started again. The zarafa-server process provides the MAPI in SOAP service required by all other Zarafa related components as shown: http://doc.zarafa.com/trunk/AdministratorManual/en-US/html/architecture.html

Robert Scheck discovered a flaw in Zarafa that could allow a remote unauthenticated attacker to crash the zarafa-server daemon, preventing access to any other legitimate Zarafa users.

Acknowledgements:

Red Hat would like to thank Robert Scheck of ETES GmbH for reporting this issue.

Unauthenticated reflected cross-site scripting (XSS) exists in Zarafa Webapp 2.0.1.47791 and earlier. NOTE: this is a discontinued product. The issue was fixed in later Zarafa Webapp versions; however, some former Zarafa Webapp customers use the related Kopano product instead.

I discovered a flaw in Zarafa WebAccess >= 7.0.0 and Zarafa WebApp (any version) that could allow a remote unauthenticated attacker to exhaust the disk space of /tmp. Depending on the setup /tmp might be on / (e.g. RHEL). Zarafa WebApp is a fork and the successor of the Zarafa WebAccess.

The affected files are /usr/share/zarafa-webaccess/senddocument.php as well as /usr/share/zarafa-webapp/senddocument.php. The default upload size is 30 MB (via /etc/httpd/conf.d/zarafa-webaccess.conf / zarafa-webapp.conf).

I do not know if $tmpname is predictable (for race conditions) but likely not. The 2nd parameter is only a prefix according to the PHP documentation of tempnam().

From my point of view the file "senddocument.php" is neither referenced nor used anywhere in the code and could be simply removed.

Upstream has been notified and I am awaiting their response. At the moment this RHBZ is only meant to have this tracked somewhere, please do not yet disclose.

Zarafa WebAccess 4.1 and WebApp uses world-readable permissions for the files in their tmp directory, which allows local users to obtain sensitive information by reading temporary session data.

Zarafa 5.00 uses world-readable permissions for the files in the log directory, which allows local users to obtain sensitive information by reading the log files.

Robert Scheck reported a number of issues with the default permissions in Zarafa[1]:

"" 1. In order to fix CVE-2014-0103, Zarafa introduced constants PASSWORDKEY and PASSWORDIV in /etc/zarafa/webaccess-ajax/config.php (Zarafa WebAccess) and /etc/zarafa/webapp/config.php (Zarafa WebApp), both are the upstream path names of a default installation, downstream names might be different. Both files have default permissions of root:root and 644, thus decryption of the symmetric encrypted passwords in the on-disk PHP session files is possible again (similar like initially described in CVE-2014-0103). Affects Zarafa WebAccess >= 7.1.10, Zarafa WebApp >= 1.6 beta.

2. The log directory /var/log/zarafa/ is shipped by default with root:root and 755 and all created log files by the Zarafa daemons have by default root:root and 644. This is leaking (depending on the log level of the given service) only e.g. subject, sender/recipient, message-id, SMTP queue id of in- and outbound e-mails but might be even a cleartext protocol dump of IMAP, POP3, CalDAV and iCal as well (including possible credentials) to any local system user. Affects Zarafa >= 5.00.

3. The directories /var/lib/zarafa-webaccess/tmp/ (Zarafa WebAccess) and /var/lib/zarafa-webapp/tmp/ (Zarafa WebApp) are read- and writable by the Apache system user by default - but also world readable for local system users (e.g. apache:apache and 755 on RHEL). Thus all the temporary session data such as uploaded e-mail attachments can be read-only accessed because all created files below previously mentioned directories have permissions 644, too. Upstream path names changed over the time and releases. Affects Zarafa WebAccess >= 4.1, Zarafa WebApp (any version).

4. The optional (but proprietary) license daemon /usr/bin/zarafa-licensed runs by default with root permissions, the subscription/license key is put into '/etc/zarafa/license/'. The license files are recommented (according upstream documentation) to be created using echo(1) which usually leads to root:root and 644. But the parent directory /etc/zarafa/license/ is shipped by default with root:root and 755. As result the key files can be accessed and copied by any local system user. Affects Zarafa >= 4.1. ""

[1] http://seclists.org/oss-sec/2014/q3/444

Zarafa Collaboration Platform 4.1 uses world-readable permissions for /etc/zarafa/license, which allows local users to obtain sensitive information by reading license files.

Robert Scheck reported that Zarafa's WebAccess stored session information, including login credentials, on-disk in PHP session files. This session file would contain a user's username and password to the Zarafa IMAP server.

If Zarafa WebAccess was run on a shared hosting site (multiple web sites on the same server), and an administrator of another server, with the ability to upload arbitrary scripts to the server, they could use this to obtain these IMAP credentials due to both sites being run by the same Apache user, and the PHP session files being owned by the same.

In a non-shared hosting environment, or one using something like SuEXEC, where the PHP session files are owned by individual users on a per-site basis, this would not be an issue. In that case, only a local user able to read these files (either as root or as the user running the Apache web server) would be able to view the credentials.

zarafa-autorespond in Zarafa Collaboration Platform (ZCP) before 7.2.1 allows local users to gain privileges via a symlink attack on /tmp/zarafa-vacation-.

provider/server/ECServer.cpp in Zarafa Collaboration Platform (ZCP) before 7.1.13 and 7.2.x before 7.2.1 allows local users to write to arbitrary files via a symlink attack on /tmp/zarafa-upgrade-lock.

kopano-ical (formerly zarafa-ical) in Kopano Groupware Core through 8.7.16, 9.x through 9.1.0, 10.x through 10.0.7, and 11.x through 11.0.1 and Zarafa 6.30.x through 7.2.x allows memory exhaustion via long HTTP headers.

I discovered (aside bug #1056767) another flaw in Zarafa that could allow a remote unauthenticated attacker to crash the zarafa-server daemon, preventing access to any other legitimate Zarafa users.

The issue affects all Zarafa versions from at least Zarafa 6.20.0 (maybe even from at least Zarafa 5.00) up to (including) Zarafa 7.1.8 final. Please note that I was not able to crash the zarafa-server daemon using official upstream Zarafa binary packages just all community builds from the source code such as shipped in Fedora. This different behaviour might be caused that upstream uses different built-time flags or other system libraries and headers.

Once the zarafa-server process crashes with a backtrace (and even all other Zarafa related daemons are still running) there is no Zarafa functionality till zarafa-server daemon is started again. The zarafa-server process provides the MAPI in SOAP service required by all other Zarafa related components as shown: http://doc.zarafa.com/trunk/AdministratorManual/en-US/html/architecture.html

Robert Scheck discovered a flaw in Zarafa that could allow a remote unauthenticated attacker to crash the zarafa-server daemon, preventing access to any other legitimate Zarafa users.

Acknowledgements:

Red Hat would like to thank Robert Scheck of ETES GmbH for reporting this issue.

Robert Scheck reported a number of issues with the default permissions in Zarafa[1]:

"" 1. In order to fix CVE-2014-0103, Zarafa introduced constants PASSWORDKEY and PASSWORDIV in /etc/zarafa/webaccess-ajax/config.php (Zarafa WebAccess) and /etc/zarafa/webapp/config.php (Zarafa WebApp), both are the upstream path names of a default installation, downstream names might be different. Both files have default permissions of root:root and 644, thus decryption of the symmetric encrypted passwords in the on-disk PHP session files is possible again (similar like initially described in CVE-2014-0103). Affects Zarafa WebAccess >= 7.1.10, Zarafa WebApp >= 1.6 beta.

2. The log directory /var/log/zarafa/ is shipped by default with root:root and 755 and all created log files by the Zarafa daemons have by default root:root and 644. This is leaking (depending on the log level of the given service) only e.g. subject, sender/recipient, message-id, SMTP queue id of in- and outbound e-mails but might be even a cleartext protocol dump of IMAP, POP3, CalDAV and iCal as well (including possible credentials) to any local system user. Affects Zarafa >= 5.00.

3. The directories /var/lib/zarafa-webaccess/tmp/ (Zarafa WebAccess) and /var/lib/zarafa-webapp/tmp/ (Zarafa WebApp) are read- and writable by the Apache system user by default - but also world readable for local system users (e.g. apache:apache and 755 on RHEL). Thus all the temporary session data such as uploaded e-mail attachments can be read-only accessed because all created files below previously mentioned directories have permissions 644, too. Upstream path names changed over the time and releases. Affects Zarafa WebAccess >= 4.1, Zarafa WebApp (any version).

4. The optional (but proprietary) license daemon /usr/bin/zarafa-licensed runs by default with root permissions, the subscription/license key is put into '/etc/zarafa/license/'. The license files are recommented (according upstream documentation) to be created using echo(1) which usually leads to root:root and 644. But the parent directory /etc/zarafa/license/ is shipped by default with root:root and 755. As result the key files can be accessed and copied by any local system user. Affects Zarafa >= 4.1. ""

[1] http://seclists.org/oss-sec/2014/q3/444

Robert Scheck reported that Zarafa's WebAccess stored session information, including login credentials, on-disk in PHP session files. This session file would contain a user's username and password to the Zarafa IMAP server.

If Zarafa WebAccess was run on a shared hosting site (multiple web sites on the same server), and an administrator of another server, with the ability to upload arbitrary scripts to the server, they could use this to obtain these IMAP credentials due to both sites being run by the same Apache user, and the PHP session files being owned by the same.

In a non-shared hosting environment, or one using something like SuEXEC, where the PHP session files are owned by individual users on a per-site basis, this would not be an issue. In that case, only a local user able to read these files (either as root or as the user running the Apache web server) would be able to view the credentials.