Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1073618 - (CVE-2014-0103) CVE-2014-0103 zarafa: passwords stored in cleartext on server
CVE-2014-0103 zarafa: passwords stored in cleartext on server
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20140318,reported=2...
: Security
Depends On: 1104803 1104804
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-06 14:48 EST by Vincent Danen
Modified: 2015-07-31 08:14 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-28 15:55:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2014-03-06 14:48:12 EST
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 19:56:12 EDT
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 11:17:14 EDT
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 06:18:21 EDT
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 06:39:52 EDT
(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 06:50:43 EDT
(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 13:47:02 EDT
(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 13:47:36 EDT
Created zarafa tracking bugs for this issue:

Affects: fedora-all [bug 1104803]
Affects: epel-all [bug 1104804]
Comment 9 Robert Scheck 2014-06-04 18:28:42 EDT
(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 02:45:59 EDT
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 03:37:10 EDT
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 13:39:55 EDT
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 13:40:20 EDT
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-27 23:24:40 EDT
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-27 23:25:28 EDT
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 16:16:37 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.