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:
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:
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?
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:
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:
So currently-supported Fedora is no longer vulnerable in this version.