Bug 660382 (CVE-2010-4409) - CVE-2010-4409 php: getSymbol() integer overflow vulnerability
Summary: CVE-2010-4409 php: getSymbol() integer overflow vulnerability
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2010-4409
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
: CVE-2011-1467 (view as bug list)
Depends On: 660517
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-12-06 17:40 UTC by Vincent Danen
Modified: 2020-02-11 00:43 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-13 17:24:38 UTC


Attachments (Terms of Use)

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. ***


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