====================================================== Name: CVE-2014-0103 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0103 Final-Decision: Interim-Decision: Modified: Proposed: Assigned: 20131203 Category: Reference: CONFIRM:https://bugzilla.redhat.com/show_bug.cgi?id=1073618 Reference: FEDORA:FEDORA-2014-7889 Reference: URL:http://lists.fedoraproject.org/pipermail/package-announce/2014-July/136044.html Reference: FEDORA:FEDORA-2014-7896 Reference: URL:http://lists.fedoraproject.org/pipermail/package-announce/2014-July/136033.html Reference: BID:68247 Reference: URL:http://www.securityfocus.com/bid/68247 WebAccess in Zarafa before 7.1.10 and WebApp before 1.6 stores credentials in cleartext, which allows local Apache users to obtain sensitive information by reading the PHP session files. Reproducible: Steps to Reproduce:
7.1.10 FTBS on mga3, mga4 and cauldron. boost related.
Created attachment 5318 [details] Build logs for mga3, mga4 and cauldron
Assignee: bugsquad => thomasSummary: CVE-2014-0103: zarafa - passwords stored in cleartext on server => zarafa - passwords stored in cleartext on server (CVE-2014-0103)
Whiteboard: (none) => MGA4TOO, MGA3TOOVersion: 3 => Cauldron
URL: (none) => http://lwn.net/Vulnerabilities/606888/
Status: NEW => ASSIGNED
Several new CVEs have just been assigned to Zarafa: http://openwall.com/lists/oss-security/2014/08/25/1
CC: (none) => luigiwalser
Not sure if we have the Zarafa webapp packaged, but this might be relevant: http://openwall.com/lists/oss-security/2014/08/28/4
Pascal got zarafa-7.1.11-1.mga5 to build in Cauldron. I'm guessing none of the CVEs mentioned in Comment 3 have been fixed yet. I'm also guessing we don't have Zarafa webapp.
We don't package the (In reply to David Walser from comment #4) > Not sure if we have the Zarafa webapp packaged, but this might be relevant: > http://openwall.com/lists/oss-security/2014/08/28/4 We don't package teh webapp
(In reply to David Walser from comment #5) > Pascal got zarafa-7.1.11-1.mga5 to build in Cauldron. I'm guessing none of > the CVEs mentioned in Comment 3 have been fixed yet. I'm also guessing we > don't have Zarafa webapp. I need to double check after installing, but we change the perms to zarafa:zarafa in %post: chown %{name}:%{name} %{_localstatedir}/log/%{name}/server.* > /dev/null 2>&1 || :
Depends on: (none) => 14016
(In reply to Thomas Spuhler from comment #6) > We don't package the (In reply to David Walser from comment #4) > > Not sure if we have the Zarafa webapp packaged, but this might be relevant: > > http://openwall.com/lists/oss-security/2014/08/28/4 > > We don't package the webapp Let me elaborate a little more on this: We don't ship the separate Zarafa WebApp (~1.6) so per the link above, we should be OK.
Fedora has issued an advisory for CVE-2014-544[7-9] and CVE-2014-5450 on August 27: https://lists.fedoraproject.org/pipermail/package-announce/2014-August/137158.html from http://lwn.net/Vulnerabilities/610413/ They fixed it in this commit: http://pkgs.fedoraproject.org/cgit/zarafa.git/commit/?id=7739e805bc476cfc3979649c5774c9a111bebe01
We'll do the same for the permissions.
I believe zarafa-7.1.11-5.mga5 fixes all of these issues in Cauldron.
Version: Cauldron => 4Whiteboard: MGA4TOO, MGA3TOO => MGA3TOO
(In reply to Thomas Spuhler from comment #10) > We'll do the same for the permissions. Fixed in cauldron
These bugs have now been resolved. The following updated packages are now in updates_testing: zarafa-7.1.11-1.mga4.src.rpm zarafa-7.1.11-1.mga4.x86_64.rpm zarafa-client-7.1.11-1.mga4.x86_64.rpm zarafa-common-7.1.11-1.mga4.x86_64.rpm zarafa-dagent-7.1.11-1.mga4.x86_64.rpm lib64zarafa-devel-7.1.11-1.mga4.x86_64.rpm zarafa-gateway-7.1.11-1.mga4.x86_64.rpm zarafa-ical-7.1.11-1.mga4.x86_64.rpm zarafa-caldav-7.1.11-1.mga4.x86_64.rpm zarafa-monitor-7.1.11-1.mga4.x86_64.rpm zarafa-spooler-7.1.11-1.mga4.x86_64.rpm zarafa-utils-7.1.11-1.mga4.x86_64.rpm lib64zarafa0-7.1.11-1.mga4.x86_64.rpm python-MAPI-7.1.11-1.mga4.x86_64.rpm php-mapi-7.1.11-1.mga4.x86_64.rpm zarafa-indexer-7.1.11-1.mga4.x86_64.rpm zarafa-webaccess-7.1.11-1.mga4.noarch.rpm zarafa-archiver-7.1.11-1.mga4.x86_64.rpm zarafa-debuginfo-7.1.11-1.mga4.x86_64.rpm and mga3 packages with same name
Assignee: thomas => qa-bugsCC: (none) => thomas
Thanks Thomas! Advisory: ======================== Updated zarafa packages fix security vulnerabilities: 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 (CVE-2014-0103). Robert Scheck discovered that the Zarafa Collaboration Platform has multiple incorrect default permissions (CVE-2014-5447, CVE-2014-5448, CVE-2014-5449, CVE-2014-5450). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0103 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-5447 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-5448 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-5449 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-5450 https://lists.fedoraproject.org/pipermail/package-announce/2014-July/136033.html https://lists.fedoraproject.org/pipermail/package-announce/2014-August/137158.html
Testing mga4 64 Edited /etc/zarafa/server.cfg and added the mysql root password.. # The password for the user (leave empty for no password) mysql_password = You could create a database add those details instead but this is Ok for testing purposes (not production). Started all the services. # systemctl start zarafa-{dagent,gateway,ical,monitor,server,spooler}.service Checked they are all running # systemctl status zarafa-{dagent,gateway,ical,monitor,server,spooler}.service Tried to log into the webaccess which should be available at http://localhost/webaccess It gives 403 Forbidden. Adding 'Require all granted' into /etc/httpd/conf/sites.d/zarafa-webaccess.conf like so.. <Directory /usr/share/zarafa-webaccess/> Require all granted # Some apache settings ..allows access but just shows a blank page. More testing info here https://bugs.mageia.org/show_bug.cgi?id=12813#c35 See 'man zarafa-admin' for the cli switches. eg. # zarafa-admin -c username -p password -f 'full name' -e 'email@address.com' User created. List users.. # zarafa-admin -l User list for Default(2): Username Fullname Homeserver ------------------------------------------- SYSTEM SYSTEM Zarafa username full name # zarafa-admin -d username User deleted. So apart from zarafa-webaccess it seems to work. Adding feedback marker for now.
Whiteboard: MGA3TOO => MGA3TOO feedback
Should probably mention to restart/reload httpd after adding 'Require all granted'.
Whiteboard: MGA3TOO feedback => MGA3TOO has_procedure feedback
Thanks Claire I will make the change for zarafa-webaccess in cauldron.
The actual webaccess doesn't appear to be working though Thomas even with the 'Require' added. Not sure what's wrong there, I'll enable debug logging in the server.cfg tomorrow unless you beat me to it. I've run out of time today.
The webaccess may never worked, but we have no bug reports. Upstream claims: Which issues have been resolved? The first issue is related to RPM-based systems. Administrators have noted that they werenât able to install WebAccess on their systems. Unfortunately, a patch from the community caused this bug. We have corrected the patch to work with RPM-based systems. Le'ts get this tested and released w/o the webaccess resolved as the security issue has been around for much too long.
Ok. Bug 14107 created for the webaccess issue. It should possibly be against Cauldron rather than mga4. Testing complete then for mga4 64 ensuring the services start/stop and a user can be created and deleted with zarafa-admin
Whiteboard: MGA3TOO has_procedure feedback => MGA3TOO has_procedure mga4-64-ok
Testing complete mga3 32 Installed php-mapi from updates before zarafa as there is a php in updates testing currently. webaccess is the same here so it's very likely Cauldron is also affected.
Whiteboard: MGA3TOO has_procedure mga4-64-ok => MGA3TOO has_procedure mga3-32-ok mga4-64-ok
php-mapi is actually part of this update, oops. Doing too many things at once. Testing mga3-64 next.
Testing complete mga3 64
Whiteboard: MGA3TOO has_procedure mga3-32-ok mga4-64-ok => MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-64-ok
Testing complete mga4 32
Whiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-64-ok => MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok
Validating. Advisory uploaded. Could sysadmin please push to 3 & 4 updates Thanks
Keywords: (none) => validated_updateWhiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-okCC: (none) => sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2014-0380.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED