Re: CVE request: Multiple incorrect default permissions in Zarafa

[cve-assign () mitre org]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I discovered that the Zarafa Collaboration Platform has multiple incorrect
> default permissions (CWE-276):

This needs separate CVE IDs because the product/version information
isn't identical in any of the cases.

> 1. In order to fix CVE-2014-0103, Zarafa introduced constants PASSWORD_KEY
> and PASSWORD_IV 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.

Use CVE-2014-5447. The scope of this CVE ID is only the 0644 permission issue,
not anything about the encryption algorithm. There is only one CVE ID because
it appears that the design was chosen once and then directly copied into
two products that have their own pathname conventions.


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

Use CVE-2014-5448. The scope of this CVE ID is only the permission issue.
In some cases of other products, there have been reported vulnerabilities
related to the existence of a protocol dump (e.g., the administrator may be
configuring protocol dumps without realizing this, or the dumping code
tried to remove especially sensitive information but failed, etc.). Any
such issue, if one exists, would have a separate CVE ID.


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

Use CVE-2014-5449. The scope of this CVE ID is only the permission
issue. There is only one CVE ID because it appears that the design was
chosen once and then directly copied into two products that have their
own pathname conventions.


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

Use CVE-2014-5450. The scope of this CVE ID is only the permission
issue. In some cases of other products, there have been reported
vulnerabilities related to the presence of sensitive data on the
command line, which is exposed to local users who run the ps program
or a similar program. Here,

  http://doc.zarafa.com/6.40/Administrator_Manual/en-US/html/_configure_the_license_manager.html

does not specify that only root may be logged in during execution of
the echo command. If this is a vulnerability in Zarafa, then a
separate CVE ID is needed.

This might be an open question. Stealing a license key might have an
adverse effect on the vendor's revenue, but perhaps doesn't have an
adverse effect on confidentiality, integrity, or availability of data
within the specific Zarafa instance. There are many possible vendor
strategies for detecting and thwarting stolen license keys. Some of
these do have an availability impact.

If the original vulnerability report was coordinated with upstream,
then maybe upstream has agreed that weak permissions for license files
were unintended. However, maybe upstream intentionally chose "echo" as
a security/complexity tradeoff (i.e., the attack is relatively
unlikely, and "echo" was an easy way to write the documentation).

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJT+20eAAoJEKllVAevmvmsbKYH/2Qz1J3Ig/VAIc8EfWmrzUoP
MGipVqXOUyI6layARuZN7NnEqVuW/tafvWwCDXMcFX21KE74w7b3RhAh574i2/wU
hwLIKrM9IrMhMblnaQH+urBoddB5Qw4FST0XgcevwQxWyak19j2CdnWrSn+yPTKo
r5vcqsy39xobYfaGLB3L5zd+j24Aqi8ZpvK56miwFtfujX1eUQsyMKCVMYDRYaPU
bSDrF7pDVYMq8oolBGVbCMwdLWGfoqYxT92Be+q7aruIfg+/7AetTSTTckO/Iid/
pbkyTF8K2Wt2OKO2GJaab0tiU5vZ1vvEfRrqVfexM+t4Eg9RlF9jyJTkG2HatN0=
=lLHM
-----END PGP SIGNATURE-----