Bug 674705 (CVE-2011-0753)

Summary:	CVE-2011-0753 php: race condition when handling many concurrent signals may lead to memory corruption
Product:	[Other] Security Response	Reporter:	Vincent Danen <vdanen>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	bressers, jorton, thoger, wnefal+redhatbugzilla
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-02-28 17:06:33 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Vincent Danen 2011-02-03 00:08:00 UTC

Common Vulnerabilities and Exposures assigned an identifier CVE-2011-0753 to
the following vulnerability:

Name: CVE-2011-0753
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0753
Assigned: 20110202
Reference: CONFIRM: http://bugs.php.net/52784
Reference: CONFIRM: http://www.php.net/ChangeLog-5.php

Race condition in the PCNTL extension in PHP before 5.3.4, when a
user-defined signal handler exists, might allow context-dependent
attackers to cause a denial of service (memory corruption) via a large
number of concurrent signals.

The upstream fix on 5.3.x is here:

http://svn.php.net/viewvc/?view=revision&amp;revision=305018

Upstream did not flag this as a security fix.  I'm not sure whether we should consider it as such either.  PCNTL seems like it would not be used very much (by the docs, it is not recommended to be used in a web environment, so would require a server written in PHP).  PCNTL support has existed since 4.3.x, so this may also affect Red Hat Enterprise Linux 4 and 5.

Comment 1 Josh Bressers 2011-02-16 20:44:40 UTC

I'll let Joe double check me up on this, but I'm pretty certain this isn't a security flaw.

I took a look at the PHP code, and it's clearly wrong, you shouldn't be able to use concurrent signals like this. The fix is easy enough, but it's not a security flaw.

If you have permissions to trigger a signal like this, you probably aren't going to be able to cross a trust boundary with this.

I'm skeptical the corruption in question could be used for anything outside of a DoS. You can't control the data structure, it's just pointers to the signal handlers.

Comment 2 Joe Orton 2011-02-17 08:53:59 UTC

I agree.  Having some kind of trust boundary between a running PHP process and processes which can signal it seems farcical: SIGKILL is a pretty effective way to "deny service".

In addition we only support pcntl in the /usr/bin/php command-line build, not in the loadable module for httpd.

Comment 3 Tomas Hoger 2011-02-28 17:06:33 UTC

I'm closing this not-a-security bug based on the comments above.  There's currently no plan to fix this as a security flaw in a security erratum.

Statement:

Red Hat does not consider this issue to be a security vulnerability since no trust boundary is crossed. Any process able to send signals to a running PHP process can terminate it by sending a carefully-chosen signal.