Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 550387 - (CVE-2009-4418) CVE-2009-4418 php: DoS via unserialize
CVE-2009-4418 php: DoS via unserialize
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
http://web.nvd.nist.gov/view/vuln/det...
impact=low,source=cve,reported=200912...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-24 17:35 EST by Vincent Danen
Modified: 2010-01-04 09:04 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-04 08:54:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2009-12-24 17:35:25 EST
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 08:54:35 EST
(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.

Note You need to log in before you can comment on or make changes to this bug.