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