Bug 1056767 - (CVE-2014-0037) CVE-2014-0037 zarafa: unauthenticated denial of service flaw
CVE-2014-0037 zarafa: unauthenticated denial of service flaw
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
impact=important,public=20140131,repo...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-22 16:41 EST by Vincent Danen
Modified: 2015-07-31 08:05 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-18 19:02:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch by ETES GmbH from 2013-10-18 (proposed to upstream) (708 bytes, patch)
2014-01-24 08:37 EST, Robert Scheck
no flags Details | Diff
Relevant diff between 7.1.8beta1-42841 and 7.1.8beta2-43059 (1.33 KB, patch)
2014-01-24 08:41 EST, Robert Scheck
no flags Details | Diff
upstream patch to correct the flaw (1.15 KB, patch)
2014-01-27 13:28 EST, Vincent Danen
no flags Details | Diff

  None (edit)
Description Vincent Danen 2014-01-22 16:41:50 EST
Robert Scheck discovered a flaw in Zarafa that could allow a remote unauthenticated attacker to crash the zarafa-server daemon, preventing access to any other legitimate Zarafa users.


Acknowledgements:

Red Hat would like to thank Robert Scheck of ETES GmbH for reporting this issue.
Comment 2 Robert Scheck 2014-01-24 08:27:55 EST
The issue affects all known Zarafa versions from at least Zarafa 5.00 up to
(including) Zarafa 7.1.8 Beta 1. Zarafa 7.1.8 Beta 2 (and later) do not have
this issue anymore. The first regular fixed release will be Zarafa 7.1.8.
Comment 3 Robert Scheck 2014-01-24 08:37:03 EST
Created attachment 854977 [details]
Patch by ETES GmbH from 2013-10-18 (proposed to upstream)
Comment 4 Robert Scheck 2014-01-24 08:41:56 EST
Created attachment 854979 [details]
Relevant diff between 7.1.8beta1-42841 and 7.1.8beta2-43059
Comment 5 Robert Scheck 2014-01-24 09:10:51 EST
From my point of view the cvss2 should be A:C rather A:P, but I might be wrong
here. 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
Comment 6 Vincent Danen 2014-01-24 11:19:05 EST
Thanks for all of this information, Robert.

In regards to the CVSSv2 scoring, please see:

https://access.redhat.com/site/security/updates/classification/

In particular the second last paragraph:

"Red Hat creates CVSSv2 scores against the entire Red Hat or Red Hat JBoss product, not against an individual component within the product. This is why you may often see differences between Red Hat scores and NVD or upstream scores. For instance, if there is a denial of service flaw against Apache, upstream may score it A:C (complete loss of availability) because their product is httpd. Red Hat would score this as A:P (partial loss of availability) because the underlying operating system (our product) is still available, while only one service is unavailable. Red Hat only uses A:C for flaws that would render the entire system unavailable (typically kernel flaws)."

This is why the CVSSv2 score is A:P, and not A:C, as in the context of the operating system itself, availability is only partially affected (taking out the Zarafa server does not take out the entire system).

From Zarafa's point of view, however, if they were to use CVSSv2 to rate this, they would likely use A:C.

I hope that explains it clearly enough.
Comment 7 Robert Scheck 2014-01-24 11:38:06 EST
Yes, indeed. I am sorry, I was not really aware about that specific paragraph.
Comment 8 Vincent Danen 2014-01-24 11:51:50 EST
No problem at all.  =)
Comment 9 Vincent Danen 2014-01-27 13:28:23 EST
Created attachment 856182 [details]
upstream patch to correct the flaw

Upstream provided this patch.
Comment 10 Robert Scheck 2014-01-27 19:58:06 EST
Even it does not make any difference for the source code itself, I would like 
to mention that attachment #856182 [details] (provided by upstream) is not identically to
the code in 7.1.8rc1-43691 (which should get gold/final today) while attachment 
#854979 (gathered from diff) is. So there was minor modification after upstream 
SVN revision 42919 (and before SVN revision 43059).
Comment 11 Robert Scheck 2014-01-27 20:09:20 EST
Most users of Zarafa at Fedora and Fedora EPEL might be able to mitigate this 
flaw by filtering Zarafa's MAPI in SOAP at the firewall or by adapting listen 
settings in the Zarafa server configuration. However once legitimate remote 
usage of MAPI in SOAP connectivity is required by the Zarafa setup, there is 
no real alternative except a fixed Zarafa version.

I have already run test builds with Zarafa 7.1.8rc1-43691 (which includes new
features and other bug fixes) and smoke tests for Fedora and Fedora EPEL, thus
I am now just waiting for the availability of the final release.
Comment 12 Robert Scheck 2014-01-30 18:40:09 EST
Meanwhile Zarafa 7.1.8 final has been released. Fixed builds for all active
branches of Fedora and Fedora EPEL have been done and 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 #1056767").
Comment 13 Vincent Danen 2014-01-31 09:16:25 EST
(In reply to Robert Scheck from comment #12)
> Meanwhile Zarafa 7.1.8 final has been released. Fixed builds for all active
> branches of Fedora and Fedora EPEL have been done and 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 #1056767").

Sorry, you should be able to do so now.  We weren't aware of the embargo lift until a few hours ago.
Comment 14 Robert Scheck 2014-01-31 18:17:41 EST
Not a problem at all, I just thought I could reference this bug report in my
Bodhi updates yesterday evening even it was embargoed. Unfortunately I had to
learn that Bodhi just accepts non-embargoed bug reports...which makes sense.
Comment 15 Fedora Update System 2014-02-15 15:02:49 EST
zarafa-7.1.8-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 16 Fedora Update System 2014-02-15 15:04:16 EST
zarafa-7.1.8-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 17 Fedora Update System 2014-02-16 06:23:06 EST
zarafa-7.1.8-1.el5, php53-mapi-7.1.8-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 18 Fedora Update System 2014-02-16 06:24:38 EST
zarafa-7.1.8-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

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