Bug 15978 - zarafa has a security issue CVE-2015-3436
Summary: zarafa has a security issue CVE-2015-3436
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 4
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL: http://lwn.net/Vulnerabilities/647496/
Whiteboard: has_procedure advisory MGA4-64-OK MGA...
Keywords: validated_update
Depends on:
Blocks:
 
Reported: 2015-05-19 01:14 CEST by Thomas Spuhler
Modified: 2015-06-08 23:18 CEST (History)
4 users (show)

See Also:
Source RPM: zarafa-7.1.11
CVE:
Status comment:


Attachments

Description Thomas Spuhler 2015-05-19 01:14:43 CEST
Fedora reported a security issue:
there is a new security flaw affecting Zarafa. It did not walk over the
mailing lists so far, however it is public. Details and patch are here:

 - https://jira.zarafa.com/browse/ZCP-13282
 - https://bugzilla.redhat.com/show_bug.cgi?id=1222151

This has been resolved in version 7.1.13

We dropped it in mga5 but we still have versions 7.1.11 in mga

I will update this package as soon as the source will be available.

Reproducible: 

Steps to Reproduce:
Thomas Spuhler 2015-05-19 01:15:55 CEST

Priority: Normal => High
Status: NEW => ASSIGNED
Assignee: bugsquad => thomas

Comment 1 Thomas Spuhler 2015-05-19 17:22:11 CEST
Zarafa fixed this issue with version 7.2.1 beta 1, however they unfortunately
did not release any source code files nor a source code patch so far. At
https://download.zarafa.com/community/beta/7.2/7.2.1-49597/ the "sourcecode"
directory is missing.
Meanwhile Zarafa has published the source code of Zarafa 7.2.1 beta 1
This bug has been resolved by upgrading to ver. 7.1.12 and attaching a patch made by Fedora from the Relevant difference between Zarafa 7.2.0 and 7.2.1 beta 1
The following files are in updates_testing:
zarafa-7.1.12-1.mga4.src.rpm
zarafa-7.1.12-1.mga4.x86_64.rpm
zarafa-client-7.1.12-1.mga4.x86_64.rpm
zarafa-common-7.1.12-1.mga4.x86_64.rpm
zarafa-dagent-7.1.12-1.mga4.x86_64.rpm
lib64zarafa-devel-7.1.12-1.mga4.x86_64.rpm
zarafa-gateway-7.1.12-1.mga4.x86_64.rpm
zarafa-ical-7.1.12-1.mga4.x86_64.rpm
zarafa-caldav-7.1.12-1.mga4.x86_64.rpm
zarafa-monitor-7.1.12-1.mga4.x86_64.rpm
zarafa-server-7.1.12-1.mga4.x86_64.rpm
zarafa-spooler-7.1.12-1.mga4.x86_64.rpm
zarafa-utils-7.1.12-1.mga4.x86_64.rpm
lib64zarafa0-7.1.12-1.mga4.x86_64.rpm
python-MAPI-7.1.12-1.mga4.x86_64.rpm
php-mapi-7.1.12-1.mga4.x86_64.rpm
zarafa-indexer-7.1.12-1.mga4.x86_64.rpm
zarafa-webaccess-7.1.12-1.mga4.noarch.rpm
zarafa-archiver-7.1.12-1.mga4.x86_64.rpm
zarafa-debuginfo-7.1.12-1.mga4.x86_64.rpm
and corresponding i586 packages

CC: (none) => thomas

Comment 2 Thomas Spuhler 2015-05-19 17:23:49 CEST
assigning it to qa

Assignee: thomas => qa-bugs
Source RPM: zarafa-7.1.1 => zarafa-7.1.11

Comment 3 David Walser 2015-05-19 17:42:39 CEST
RedHat description for this is:
Guido Günther detected and reported that replacing "/tmp/zarafa-upgrade-lock"
by a symlink makes the zarafa-server process following that symlink and thus 
allows to overwrite arbitrary files in the filesystem (assuming zarafa-server
runs as root which is not case by default at Fedora, but upstream default).
One just needs write permissions in /tmp and wait until the zarafa-server is
restarted.

First of all, we have protected_symlinks so it will not follow a symlink if you make one, second of all, I'm guessing if Fedora's package doesn't run as root, ours doesn't either.  So this would just be a minor bugfix for us.  Do we know what impact it has on our package if someone creates that symlink?

Priority: High => Normal
Severity: major => normal

Comment 4 Thomas Spuhler 2015-05-20 00:23:36 CEST
I am not even sure anybody uses the Mageia package.We had no bug reports when it didn't run.
Robert Scheck 2015-05-20 22:11:16 CEST

CC: (none) => mageia.org

Comment 5 Robert Scheck 2015-05-20 22:18:13 CEST
(In reply to David Walser from comment #3)
> First of all, we have protected_symlinks so it will not follow a symlink if
> you make one, second of all, I'm guessing if Fedora's package doesn't run as
> root, ours doesn't either.  So this would just be a minor bugfix for us.  Do
> we know what impact it has on our package if someone creates that symlink?

You can verify this using "grep ^run_as_ /etc/zarafa/*.cfg", according to
https://svnweb.mageia.org/packages/updates/4/zarafa/current/SPECS/zarafa.spec?view=annotate the daemons are not running as root since at least subversion
rev. 62086 (if that helps), which seems to be the initial import into Mageia.
Comment 6 Herman Viaene 2015-06-08 15:05:09 CEST
MGA4-32 on AcerD620 Xfce.
Confirm that zarafa is running as user zarafa as per Comment 5 above.
On installation, found no zarafa-debuginfo package, but that should not be a stopper?
Applied change in /etc/zarafa/server.cfg as per bug14993, and chacked that /etc/httpd/conf/sites.d/zarafa-webaccess.conf has per bug14993 Comment16
Then as root
>systemctl start zarafa-server , returns nothing
and
> systemctl status -l zarafa-server
zarafa-server.service - LSB: Zarafa Collaboration Platform's Storage Server
   Loaded: loaded (/etc/rc.d/init.d/zarafa-server)
   Active: active (running) since ma 2015-06-08 14:49:28 CEST; 4s ago
  Process: 3289 ExecStart=/etc/rc.d/init.d/zarafa-server start (code=exited, status=0/SUCCESS)
 Main PID: 3302 (zarafa-server)
   CGroup: /system.slice/zarafa-server.service
           ââ3302 /usr/bin/zarafa-server -c /etc/zarafa/server.cfg

jun 08 14:49:28 mach6.hviaene.thuis systemd[1]: Starting LSB: Zarafa Collaboration Platform's Storage Server...
jun 08 14:49:28 mach6.hviaene.thuis zarafa-server[3289]: Starting zarafa-server: [  OK  ]
jun 08 14:49:28 mach6.hviaene.thuis systemd[1]: Started LSB: Zarafa Collaboration Platform's Storage Server.
and browsing to http://localhost/webaccess gives zarafa-webacces logon page

CC: (none) => herman.viaene
Whiteboard: (none) => MGA4-32-OK

Comment 7 Herman Viaene 2015-06-08 15:57:36 CEST
MGA4-64 on HP-Probook 6555b.
Confirm results as per Comment 6 above.

Whiteboard: MGA4-32-OK => has_procedure MGA4-64-OK MGA4-32-OK

Comment 8 David Walser 2015-06-08 19:45:56 CEST
Fedora has issued an advisory for this on May 19:
https://lists.fedoraproject.org/pipermail/package-announce/2015-June/159497.html

URL: (none) => http://lwn.net/Vulnerabilities/647496/

Comment 9 claire robinson 2015-06-08 21:29:09 CEST
Validating. Advisory uploaded.

Please push to 4 updates

Thanks!

Keywords: (none) => validated_update
Whiteboard: has_procedure MGA4-64-OK MGA4-32-OK => has_procedure advisory MGA4-64-OK MGA4-32-OK
CC: (none) => sysadmin-bugs

Comment 10 Mageia Robot 2015-06-08 23:18:38 CEST
An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2015-0054.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED


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