I discovered a flaw in Zarafa WebAccess >= 7.0.0 and Zarafa WebApp (any version) that could allow a remote unauthenticated attacker to exhaust the disk space of /tmp. Depending on the setup /tmp might be on / (e.g. RHEL). Zarafa WebApp is a fork and the successor of the Zarafa WebAccess. The affected files are /usr/share/zarafa-webaccess/senddocument.php as well as /usr/share/zarafa-webapp/senddocument.php. The default upload size is 30 MB (via /etc/httpd/conf.d/zarafa-webaccess.conf / zarafa-webapp.conf). I do not know if $tmpname is predictable (for race conditions) but likely not. The 2nd parameter is only a prefix according to the PHP documentation of tempnam(). From my point of view the file "senddocument.php" is neither referenced nor used anywhere in the code and could be simply removed. Upstream has been notified and I am awaiting their response. At the moment this RHBZ is only meant to have this tracked somewhere, please do not yet disclose.
Acknowledgements: Red Hat would like to thank Robert Scheck of the Fedora Project for reporting this issue.
Upstream plans to ship a fix with 7.1.12 and 7.2.0 (which do not have a public release date so far) however I also did not receive any objection against public disclosure.
Hi Robert, please mail secalert when you are ready for this bug to be public. Also, will you communicate this issue to other vendors in advance (via <http://oss-security.openwall.org/wiki/mailing-lists/distros>, for example)? We could mail on your behalf if you want.
(In reply to Murray McAllister from comment #3) > Also, will you communicate this issue to other vendors in advance (via > <http://oss-security.openwall.org/wiki/mailing-lists/distros>, for example)? > We could mail on your behalf if you want. That's a good idea! Could you please do so and put me on Cc: simply? I do not know if it's clever to send such an e-mail myself because I never did before. And please let me know if you need something additionally to the description.
(In reply to Robert Scheck from comment #4) > (In reply to Murray McAllister from comment #3) > > Also, will you communicate this issue to other vendors in advance (via > > <http://oss-security.openwall.org/wiki/mailing-lists/distros>, for example)? > > We could mail on your behalf if you want. > > That's a good idea! Could you please do so and put me on Cc: simply? I do not > know if it's clever to send such an e-mail myself because I never did before. > And please let me know if you need something additionally to the description. Thanks Robert. The distros list prefers a 2 week embargo, so we should not post to that until you are ready for it to be public within 2 weeks of the post. Do you have a patch that could be sent, or would this post be about opening a discussion on how to fix the issue?
(In reply to Murray McAllister from comment #5) > Thanks Robert. The distros list prefers a 2 week embargo, so we should not > post to that until you are ready for it to be public within 2 weeks of the > post. Given that upstream did not object against public disclosure (neither to me directly nor to you from what I am aware of), let's do this in a responsible way - where I treat your suggestion as suitable. > Do you have a patch that could be sent, or would this post be about opening > a discussion on how to fix the issue? Of course I only can guess what upstream really will do but the affected file is not used inside of Zarafa WebAccess or WebApp the fix is IMHO: rm -f /usr/share/zarafa-webaccess/senddocument.php # Zarafa WebAccess rm -f /usr/share/zarafa-webapp/senddocument.php # Zarafa WebApp And if that still raises space for discussions let them happen ;-)
Hi Robert, I let this one slip, sorry - and about to add more delay: You sent us a PDF with the statuses of various issues. Inside that: CWE-306 / CWE-400 / RHBZ 1139442: Possibility to fill /tmp remotely fix is in QA, will be shipped in version 7.1.12 and 7.2.0 Should we align the distros notification with the release schedule of 7.1.12 and 7.2.0? Will it cause you grief with them if the issue is made public before they fix it?
(In reply to Murray McAllister from comment #7) > I let this one slip, sorry - and about to add more delay: You sent us a PDF > with the statuses of various issues. Inside that: Not an issue to me, I meanwhile was 1.5 weeks sick. The PDF you refer to is from the management of upstream - and is also the best reply I received regarding this issue. > Should we align the distros notification with the release schedule of 7.1.12 > and 7.2.0? I'm unfortunately not aware of any planned release date of 7.1.12 or 7.2.0; I guess you are looking for a CRD (Coordinated Release Date). Rumours for 7.2.0 are from Q3/2014 to Q1/2015 [1], but 7.1.12 is overdue according to their Jira roadmap [2] (as of writing it shows 2014-09-02). Normally there is a beta/preview about 14+ days available before a final release [3]. Doing the math based on previous releases (one .z release per two months) shows a slight delay due to the lack of a beta/preview, too. > Will it cause you grief with them if the issue is made public before they > fix it? Good question, I have no idea. [1] http://doc.zarafa.com/trunk/Support_Lifecycle_Policy/en-US/html/_major_release_cycle.html [2] https://jira.zarafa.com/browse/ZCP/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel [3] https://download.zarafa.com/community/beta/7.1/
Zarafa published yesterday evening Zarafa WebApp 2.0 beta 3 (SVN 46848) which fixes the flaw (the naming on their server is somehow inconsistent: directory "beta1" is "b2" and directory "beta2" is "b3". Given there was a "b1" as well, it's "beta3" or so?) at http://download.zarafa.com/community/beta/WebApp/2.0/ Given there is a public available fix now it makes sense to me to send a mail to the oss-sec list later.
On Friday evening Zarafa 7.2.0 beta 1 (SVN 47004) was released which fixes the flaw in WebAccess as well - and mentions the fix in the changelog, too: - http://download.zarafa.com/community/beta/7.2/changelog-7.2.txt - http://download.zarafa.com/community/beta/7.2/7.2.0beta1-47004/ And please lift embargo: http://seclists.org/oss-sec/2014/q4/953
CVE-2014-9465 was assigned as per http://seclists.org/oss-sec/2015/q1/16