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.

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.

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