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.
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.
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).
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.
(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.
(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.
(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.
Created zarafa tracking bugs for this issue: Affects: fedora-all [bug 1104803] Affects: epel-all [bug 1104804]
(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.
For the sake of completeness, php-mcrypt is not available in Red Hat Enterprise Linux, only via php-extras in EPEL.
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 :)
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.
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.
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.
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.
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.