I discovered (aside bug #1056767) another flaw in Zarafa that could allow a remote unauthenticated attacker to crash the zarafa-server daemon, preventing access to any other legitimate Zarafa users. The issue affects all Zarafa versions from at least Zarafa 6.20.0 (maybe even from at least Zarafa 5.00) up to (including) Zarafa 7.1.8 final. Please note that I was not able to crash the zarafa-server daemon using official upstream Zarafa binary packages just all community builds from the source code such as shipped in Fedora. This different behaviour might be caused that upstream uses different built-time flags or other system libraries and headers. Once the zarafa-server process crashes with a backtrace (and even all other Zarafa related daemons are still running) there is no Zarafa functionality till zarafa-server daemon is started again. The zarafa-server process provides the MAPI in SOAP service required by all other Zarafa related components as shown: http://doc.zarafa.com/trunk/Administrator_Manual/en-US/html/_architecture.html
Created attachment 857652 [details] Patch suggestion (applicable to Zarafa 7.1.8 Beta 2 and later)
While updating Zarafa 7.1.8 (due to bug #1056767) I included the patch from comment #1 and now there are fixed builds for all active branches of Fedora and Fedora EPEL and were submitted via Bodhi: https://admin.fedoraproject.org/updates/zarafa-7.1.8-1.fc20 https://admin.fedoraproject.org/updates/zarafa-7.1.8-1.fc19 https://admin.fedoraproject.org/updates/zarafa-7.1.8-1.el6 https://admin.fedoraproject.org/updates/zarafa-7.1.8-1.el5,php53-mapi-7.1.8-1.el5 Unfortunately I am not able to reference this bug in Bodhi until the embargo has been removed ("You are not authorized to access bug #1059903").
Hi, Robert. Thanks for filing this. This is the second issue you had referred to, correct? And not at all related to CVE-2014-0037 right? Upstream is still unaware of this one?
Acknowledgements: Red Hat would like to thank Robert Scheck of ETES GmbH for reporting this issue.
(In reply to Vincent Danen from comment #3) > Hi, Robert. Thanks for filing this. This is the second issue you had > referred to, correct? And not at all related to CVE-2014-0037 right? Yes, this is the second issue. This issue is similar - maybe you can simply have a look to the patch of this one and that one of CVE-2014-0037: This one refers to a NULL pointer of the password, the CVE-2014-0037 refers to a NULL pointer of the username. Obviously the exploitation is quite similar, too. You still can exploit this issue even when CVE-2014-0037 is fixed (and also the other way round). The two issues are related that way that they are both in the same source code functions and both related to authentication data. Do these information help you? If you say that these should be treated like one issue, let's do it...I'm not an expert here. I am also sorry that I did not figure out this issue already months ago (but upstream did neither). > Upstream is still unaware of this one? I noticed upstream yesterday evening via e-mail about the issue including the patch and also the fact that Fedora is shipping the patch already - see: http://pkgs.fedoraproject.org/cgit/zarafa.git/tree/zarafa-7.1.8-nullptr.patch Unfortunately there was no reply by upstream so far. Shall I send a reminder having the RHSRT on Cc? Does it make sense to keep this one embargoed (as the patch is public)? I marked this only as such because the referenced CVE-2014-0037 was embargoed at the time of opening this one. If you manage to exploit CVE-2014-0037 it is more than trivial to exploit this issue, too.
Vincent, I sent an e-mail to upstream having the RHSRT on Cc about a week ago but did not get any objections. Can you please make a decision if this worth another CVE or not, but would you anyway please lift the embargo afterwards?
Sorry for the delay on this one. Yes, it needs another CVE (as CVE-2014-0037 was fixed, this one was not, doesn't matter if it's in the same function or found by the same person (had they been fixed at the same time it would have been a different story)). This issue has been assigned the name CVE-2014-0079. When you communicate this to upstream, can you let them know the CVE name as well please? I can lift the embargo whenever you like. It might be nice to let upstream know before we do though, so I'm not going to open it now. Please give me an explicit ack to opening this bug and I will do so. Thanks (and my apologies again for the delay).
Vincent, thank you very much for taking care! And don't worry about the delay.
This has been already corrected in the recent Zarafa 7.1.8 builds with this patch: http://pkgs.fedoraproject.org/cgit/zarafa.git/tree/zarafa-7.1.8-nullptr.patch?h=f20 So currently-supported Fedora is no longer vulnerable in this version.