Hide Forgot
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.
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.
Created attachment 854977 [details] Patch by ETES GmbH from 2013-10-18 (proposed to upstream)
Created attachment 854979 [details] Relevant diff between 7.1.8beta1-42841 and 7.1.8beta2-43059
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
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.
Yes, indeed. I am sorry, I was not really aware about that specific paragraph.
No problem at all. =)
Created attachment 856182 [details] upstream patch to correct the flaw Upstream provided this patch.
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).
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.
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").
(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.
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.
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.
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.
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.
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.