Bug 1059903 (CVE-2014-0079)

Summary: CVE-2014-0079 zarafa: unauthenticated denial of service flaw
Product: [Other] Security Response Reporter: Robert Scheck <redhat-bugzilla>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: security-response-team, vdanen, vkrizan
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=important,public=20140212,reported=20131029,source=customer,cvss2=5/AV:N/AC:L/Au:N/C:N/I:N/A:P,fedora-all/zarafa=affected,epel-all/zarafa=affected
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-02-14 10:37:07 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 1057739    
Description Flags
Patch suggestion (applicable to Zarafa 7.1.8 Beta 2 and later) none

Description Robert Scheck 2014-01-30 16:59:49 EST
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:
Comment 1 Robert Scheck 2014-01-30 17:11:43 EST
Created attachment 857652 [details]
Patch suggestion (applicable to Zarafa 7.1.8 Beta 2 and later)
Comment 2 Robert Scheck 2014-01-30 18:42:15 EST
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").
Comment 3 Vincent Danen 2014-01-31 13:49:52 EST
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?
Comment 4 Vincent Danen 2014-01-31 13:52:14 EST

Red Hat would like to thank Robert Scheck of ETES GmbH for reporting this issue.
Comment 5 Robert Scheck 2014-01-31 19:38:53 EST
(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.
Comment 6 Robert Scheck 2014-02-09 18:30:59 EST
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?
Comment 7 Vincent Danen 2014-02-12 18:59:54 EST
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).
Comment 8 Robert Scheck 2014-02-12 20:33:21 EST
Vincent, thank you very much for taking care! And don't worry about the delay.
Comment 9 Vincent Danen 2014-02-14 10:37:07 EST
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.