Bug 660382 (CVE-2010-4409)

Summary: CVE-2010-4409 php: getSymbol() integer overflow vulnerability
Product: [Other] Security Response Reporter: Vincent Danen <vdanen>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: caolanm, fedora, jlieskov, jorton, rpm
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: 2010-12-13 17:24:38 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:
Bug Depends On: 660517    
Bug Blocks:    

Description Vincent Danen 2010-12-06 17:40:44 UTC
It was discovered [1] that PHP failed to properly sanitize input passed to the getSymbol() function, which contains an integer overflow vulnerability, that could possibly allow a remote attacker to cause a segmentation fault in PHP, leading to a denial of service.

This flaw only affects PHP >= 5.3.0 [2] and has been fixed in upstream svn [3].

[1] http://www.kb.cert.org/vuls/id/479900
[2] http://php.net/manual/en/numberformatter.getsymbol.php
[3] http://svn.php.net/viewvc?view=revision&revision=305571

Comment 1 Vincent Danen 2010-12-06 22:58:09 UTC
This was assigned CVE-2010-4409.

Comment 2 Vincent Danen 2010-12-06 23:39:08 UTC
Created php tracking bugs for this issue

Affects: fedora-all [bug 660517]

Comment 4 Tomas Hoger 2010-12-07 10:17:58 UTC
Is this security issue?  It seems quite unlikely to have getSymbol's attr argument exposed to untrusted inputs, it's something that's under script author's control and not crossing trust boundary.

Additionally, linked upstream patch only takes care of getSymbol crash as:

numfmt_get_symbol(numfmt_create("en", NumberFormatter::PATTERN_DECIMAL), 2147483648)

but the same issue affects setSymbol too, which seems more likely to be something more than a crash, and does not seem to be addressed yet:

numfmt_set_symbol(numfmt_create("en", NumberFormatter::PATTERN_DECIMAL), 2147483648, "+")

In both cases, it's only PHP exposing ICU bug (unum_getSymbol and unum_setSymbol not checking symbol argument properly):

http://bugs.icu-project.org/trac/browser/icu/trunk/source/i18n/unum.cpp?rev=28789#L852
http://bugs.icu-project.org/trac/browser/icu/trunk/source/i18n/unum.cpp?rev=28789#L879

Comment 5 Tomas Hoger 2010-12-07 10:52:45 UTC
(In reply to comment #4)
> In both cases, it's only PHP exposing ICU bug (unum_getSymbol and
> unum_setSymbol not checking symbol argument properly):

http://bugs.icu-project.org/trac/ticket/8218

Comment 6 Joe Orton 2010-12-08 10:32:54 UTC
Per comment 4; if there was a strong API guarantee that those ICU functions guarantee to safety-check arguments then it would seem reasonable to only fix ICU here.  There isn't really such a strong guarantee documented in the API, anywhere I can find, but the code *does* do some (in this case deficient) safety checking...

Comment 7 Tomas Hoger 2010-12-10 07:26:02 UTC
(In reply to comment #4)

> but the same issue affects setSymbol too, which seems more likely to be
> something more than a crash, and does not seem to be addressed yet:
> 
> numfmt_set_symbol(numfmt_create("en", NumberFormatter::PATTERN_DECIMAL),
> 2147483648, "+")

http://bugs.php.net/bug.php?id=53512
http://svn.php.net/viewvc?view=revision&revision=306154

Comment 8 Vincent Danen 2010-12-13 16:55:46 UTC
Statement:

This issue did not affect the versions of PHP as shipped with Red Hat Enterprise Linux 4 and 5.  The getSymbol() and setSymbol() functions are unlikely to ever receive untrusted input as an $attr argument, and it is even less likely that they would receive such input when only a small set of pre-defined constants is expected.  As a result, this flaw can only be triggered by the script author and cannot be used to cross trust boundaries.  The Red Hat Security Response Team does not consider it to be security-relevant.

Comment 9 Tomas Hoger 2011-03-25 18:13:44 UTC
*** Bug 690894 has been marked as a duplicate of this bug. ***