Bug 678885 (CVE-2011-0420) - CVE-2011-0420 php: missing $size checks in grapheme_extract()
Summary: CVE-2011-0420 php: missing $size checks in grapheme_extract()
Alias: CVE-2011-0420
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2011-02-20 15:51 UTC by Jan Lieskovsky
Modified: 2019-09-29 12:42 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-03-01 13:50:19 UTC

Attachments (Terms of Use)

Description Jan Lieskovsky 2011-02-20 15:51:39 UTC
Common Vulnerabilities and Exposures assigned an identifier CVE-2011-0420 to
the following vulnerability:

The grapheme_extract function in the Internationalization extension
(Intl) for ICU for PHP 5.3.5 allows context-dependent attackers to
cause a denial of service (crash) via an invalid size argument, which
triggers a NULL pointer dereference.

[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0420
[2] http://securityreason.com/achievement_securityalert/94
[3] http://www.securityfocus.com/archive/1/archive/1/516504/100/0/threaded
[4] http://www.securityfocus.com/archive/1/516518/100/0/threaded
[5] http://www.exploit-db.com/exploits/16182
[6] http://svn.php.net/viewvc?view=revision&revision=306449
[7] http://www.kb.cert.org/vuls/id/210829
[8] http://www.securityfocus.com/bid/46429
[9] http://xforce.iss.net/xforce/xfdb/65437

Comment 1 Jan Lieskovsky 2011-02-20 16:04:39 UTC
This issue did NOT affect the versions of the php package, as shipped
with Red Hat Enterprise Linux 3, 4, or 5.

This issue affects the version of the php53 package, as shipped with
Red Hat Enterprise Linux 5.

This issue affects the version of the php package, as shipped with
Red Hat Enterprise Linux 6.


This issue affects the versions of the php package, as shipped with
Fedora release of 13 and 14.

Comment 4 Tomas Hoger 2011-02-28 11:37:18 UTC
Looks like this is another SecurityReason advisory where the reporter did not spend much time investigating the crash they were seeing.  This is not a NULL pointer dereference flaw.  The reproducer triggers the crash around this line in grapheme_extract:

  RETURN_STRINGL(((char *)pstr), nsize, 1);

pstr is non-NULL pointer to the $haystack input string (usually $start bytes away from the beginning).  This leads to memcpy call where nsize == -1 is type casted to 0xffffffff, which leads to the input buffer over-read eventually.

Theoretically, this may possibly lead to the information leak (over-reading $haystack input buffer up to the first non-ascii character), but this would require to have mapped memory and no non-ascii character after the $haystack $start position for at least 2^31 bytes.

The grapheme functions were introduced upstream in 5.3.0 and still seems rarely used.  It also seems $size is not too likely to come from an untrusted source, but I'm not sure if it's unlikely enough to consider this script author issue only.  Very low impact anyway.

Comment 5 Tomas Hoger 2011-02-28 12:56:34 UTC
Joe, I wanted to ask, do you think it's safe to assume this to be script author only?

Comment 6 Joe Orton 2011-02-28 13:50:16 UTC
I think it's reasonable to assume that the 'size' argument would be under control of the script author. I struggle to imagine how this function could be useful in any context where any arguments are untrusted input.

Comment 7 Tomas Hoger 2011-03-01 13:50:19 UTC
I agree with that.  Given that it's unlikely to use untrusted size values, the limited impact of the flaw (crash only), and the limited use of the functionality, there's currently no plan to address this in future security errata for PHP.  If anyone needs to have this fix backported to specific RHEL version, please open a request against specific RHEL/php version.


Red Hat does not consider this flaw to be a security issue. The size argument of the grapheme_extract function is unlikely to from an untrusted source unfiltered, therefore the value passed to the function is under the the full control of the script author and no trust boundary is crossed.

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