Bug 550387 (CVE-2009-4418)

Summary:	CVE-2009-4418 php: DoS via unserialize
Product:	[Other] Security Response	Reporter:	Vincent Danen <vdanen>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	jorton, qe-baseos-apps
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
URL:	http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-4418
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-01-04 13:54:35 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 2009-12-24 22:35:25 UTC

Common Vulnerabilities and Exposures assigned an identifier CVE-2009-4418 to
the following vulnerability:

Name: CVE-2009-4418
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4418
Assigned: 20091224
Reference: MISC: http://www.suspekt.org/2009/11/28/shocking-news-in-php-exploitation/
Reference: MISC: http://www.suspekt.org/downloads/POC2009-ShockingNewsInPHPExploitation.pdf

The unserialize function in PHP 5.3.0 and earlier allows
context-dependent attackers to cause a denial of service (resource
consumption) via a deeply nested serialized variable, as demonstrated
by a string beginning with a:1: followed by many {a:1: sequences.


This is discussed on page 31 of the PDF referenced.

Comment 2 Tomas Hoger 2010-01-04 13:54:35 UTC

(In reply to comment #0)
> This is discussed on page 31 of the PDF referenced.  

That Stefan Esser's presentation is also quite clear in one point: unserialize()  should never be used on user input.  So the input passed to unserialize() should be trusted with the script author's privileges.

As far as I can see, largish input as described in the PDF will trigger deep recursion, resulting in a stack memory exhaustion, limiting the impact to a crash.

So this is an interpreter crash triggered by the script author, which is not a security issue.  Once the issue is fixed upstream (not fixed in current versions 5.3.1 / 5.2.12), updated PHP versions may appear in the future Red Hat Enterprise Linux and Fedora versions.