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. References: [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
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.
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.
Joe, I wanted to ask, do you think it's safe to assume this to be script author only?
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.
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. Statement: 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.