|Summary:||CVE-2014-0103 zarafa: passwords stored in cleartext on server|
|Product:||[Other] Security Response||Reporter:||Vincent Danen <vdanen>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||jrusnack, redhat-bugzilla, robert.scheck, security-response-team, vkrizan|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-07-28 19:55:15 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1104803, 1104804|
Description Vincent Danen 2014-03-06 19:48:12 UTC
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.
Comment 2 Vincent Danen 2014-03-18 23:56:12 UTC
Upstream has indicated that: " The encryption is implemented in the webapp (1.6) and webaccess. The user password are encrypted using openssl_encrypt / _decrypt The key is obtained form the webapp.conf file. It is true that once you obtain root acces it is possible to obtain the encryption key, and you are able to decrypt the user password. But once you have root access, it is always possible to obtain the user passwords. " Note that these fixed versions are not yet available.
Comment 3 Robert Scheck 2014-03-31 15:17:14 UTC
Upstream released WebAccess 7.1.9-44333 a few minutes ago - which is still vulnerable. WebApp 1.6 has not been released so far (the latest version is 1.5 which is still the same version like at initially opening this RHBZ).
Comment 4 Robert Scheck 2014-06-04 10:18:21 UTC
Upstream released WebAccess 7.1.10-44973 yesterday. That release contains the fix mentioned in comment #2. Unfortunately the functions openssl_encrypt and openssl_decrypt are only available starting with PHP 5.3, thus Fedora EPEL 5 will still be vulnerable as RHEL 5 is shipping PHP 5.1. WebApp 1.5-44025 (as shipped/bundled by upstream with Zarafa 7.1.10-44973) is still vulnerable and does not include the fix. As of writing I can not see that changelog mentions that fix, too.
Comment 5 Tomas Hoger 2014-06-04 10:39:52 UTC
(In reply to Robert Scheck from comment #4) > Unfortunately the functions openssl_encrypt and openssl_decrypt are only > available starting with PHP 5.3, thus Fedora EPEL 5 will still be vulnerable > as RHEL 5 is shipping PHP 5.1. Red Hat Enterprise Linux 5 also provides PHP 5.3 via php53 packages.
Comment 6 Robert Scheck 2014-06-04 10:50:43 UTC
(In reply to Tomas Hoger from comment #5) > Red Hat Enterprise Linux 5 also provides PHP 5.3 via php53 packages. That is correct, but not everybody might be able to use them easily - some packages might have requirements for the original PHP packages. And PHP 5.1 and 5.3 are IIRC not ABI compatible once it comes to e.g. PHP modules.
Comment 7 Vincent Danen 2014-06-04 17:47:02 UTC
(In reply to Robert Scheck from comment #6) > (In reply to Tomas Hoger from comment #5) > > Red Hat Enterprise Linux 5 also provides PHP 5.3 via php53 packages. > > That is correct, but not everybody might be able to use them easily - some > packages might have requirements for the original PHP packages. And PHP 5.1 > and 5.3 are IIRC not ABI compatible once it comes to e.g. PHP modules. Then I suppose we would have to make a local modification to our Zarafa package to use some different functions as it's not reasonable to backport these functions to earlier versions of PHP simply for use by something in EPEL5. You may want to bring that up with upstream if they care about compatibility with older versions.
Comment 8 Vincent Danen 2014-06-04 17:47:36 UTC
Created zarafa tracking bugs for this issue: Affects: fedora-all [bug 1104803] Affects: epel-all [bug 1104804]
Comment 9 Robert Scheck 2014-06-04 22:28:42 UTC
(In reply to Vincent Danen from comment #7) > You may want to bring that up with upstream if they care about compatibility > with older versions. I informed upstream about that (because they still support RHEL 5 and SLES 10 which both ship PHP < 5.3 by default) in general and meanwhile also sent a patch suggestion that uses php-mcrypt if php-openssl is not available.
Comment 10 Tomas Hoger 2014-06-05 06:45:59 UTC
For the sake of completeness, php-mcrypt is not available in Red Hat Enterprise Linux, only via php-extras in EPEL.
Comment 11 Robert Scheck 2014-06-05 07:37:10 UTC
Right, but for Zarafa in EPEL 5 this IMHO shouldn't be an issue: Multiple non-optional Zarafa dependencies can be only satisfied using EPEL such as boost141, clucene, kyotocabinet, libical and libvmime. My patch suggestion is to prefer php-openssl and only use php-mcrypt alternatively. But thank you very much for thinking about it and mentioning this :)
Comment 12 Fedora Update System 2014-07-27 17:39:55 UTC
zarafa-7.1.10-2.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
Comment 13 Fedora Update System 2014-07-27 17:40:20 UTC
zarafa-7.1.10-2.el5, php53-mapi-7.1.10-2.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
Comment 14 Fedora Update System 2014-07-28 03:24:40 UTC
zarafa-7.1.10-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Comment 15 Fedora Update System 2014-07-28 03:25:28 UTC
zarafa-7.1.10-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Comment 16 Robert Scheck 2014-07-28 20:16:37 UTC
This flaw is only solved for EPEL 5 users running zarafa-webaccess using php53; upstream is working on a fix for Zarafa 7.1.12 to cover also PHP < 5.3.