Bug 1139442 (CVE-2014-9465)

Summary:	CVE-2014-9465 zarafa: unauthenticated denial of service flaw
Product:	[Other] Security Response	Reporter:	Robert Scheck <redhat-bugzilla>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	jrusnack, security-response-team
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	zarafa-7.1.12-1	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-04-07 19:54:23 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Robert Scheck 2014-09-08 22:52:59 UTC

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.

Comment 1 Murray McAllister 2014-09-15 05:09:52 UTC

Acknowledgements:

Red Hat would like to thank Robert Scheck of the Fedora Project for reporting this issue.

Comment 2 Robert Scheck 2014-10-23 22:05:02 UTC

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.

Comment 3 Murray McAllister 2014-10-24 02:11:10 UTC

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.

Comment 4 Robert Scheck 2014-10-24 10:15:29 UTC

(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.

Comment 5 Murray McAllister 2014-10-27 05:13:59 UTC

(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?

Comment 6 Robert Scheck 2014-10-27 06:45:58 UTC

(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 ;-)

Comment 7 Murray McAllister 2014-11-04 07:06:52 UTC

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?

Comment 8 Robert Scheck 2014-11-19 20:52:53 UTC

(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/

Comment 9 Robert Scheck 2014-11-21 10:22:39 UTC

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.

Comment 10 Robert Scheck 2014-12-07 12:30:49 UTC

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

Comment 11 Robert Scheck 2015-01-05 17:05:22 UTC

CVE-2014-9465 was assigned as per http://seclists.org/oss-sec/2015/q1/16