Bug #74603 [Csd]: PHP INI Parsing Stack Buffer Overflow Vulnerability

Edit report at https://bugs.php.net/bug.php?id=74603&edit=1 ID: 74603 User updated by: l dot wei at ntu dot edu dot sg Reported by: l dot wei at ntu dot edu dot sg Summary: PHP INI Parsing Stack Buffer Overflow Vulnerability Status: Closed Type: Bug Package: Scripting Engine problem Operating System: * PHP Version: 5.6.30 Assigned To: stas Block user comment: N Private report: N CVE-ID: 2017-11628 New Comment: Normally we audit functions that take external input, as they involve assumptions that could be challenged under certain settings, or the specification. As we see it, this issue does open additional possibilities than just accepting an ini setting or rejecting it. An unprotected ini vector, if requiring lower privilege, could be used to chain with other issues and cross the boundary. You are right this is just theoretical. At least I don't see how this is more theoretical than those full bunch of integer overflows triggered by scripting arguments. Blame the inconsistency of your policy handling such issues. We work for free too. Previous Comments: ------------------------------------------------------------------------ [2017-08-17 09:18:03] zeev@php.net I'm changing this back to 'Bug'. When coming to determine whether something is a security issue or not, we have to consider the likelihood of a real world attack vector. In here, it's low to non-existent - since even in apps that use parse_ini_file() - they do that for their own configuration. If you're an app admin trying to 'attack' your own deployment, be our guest and succeed. And if you're a user that installs an app from an untrusted source (that may come bundled with a malicious .ini file) - you have bigger issues than this buffer overflow - as an app from an untrusted source could already do pretty much everything the user credentials allow. Loading your configuration from a remote untrusted source? I just don't see that happening. The only scenario I can think of this can be a security issue, is an app that manages or analyzes uploaded/remote .ini files. That is such a narrow/theoretical use case I don't think we should pay attention to it. Perhaps we should add a new 'Security (very minor)' category, or something of the sort - but these sorts of bugs can't be in the same category as, say, a remote vulnerability. ------------------------------------------------------------------------ [2017-07-26 01:44:58] chiuado at gmail dot com Understood, thanks for the clearly explanation! ------------------------------------------------------------------------ [2017-07-26 01:36:33] l dot wei at ntu dot edu dot sg CVE-2017-11628 is assigned for this issue. ------------------------------------------------------------------------ [2017-07-25 11:21:08] l dot wei at ntu dot edu dot sg static void zend_ini_do_op(char type, zval *result, zval *op1, zval *op2) { int i_result; int i_op1, i_op2; char str_result[MAX_LENGTH_OF_LONG]; On the mentioned Windows build, checking the following two: bp !php5ts+436f0 // ini_parse() bp !php5ts+375d20 // zend_ini_do_op() Stack cookie protection is on, with canary store in [ebp-4]. The mitigation re-ordered the 4-byte aligned char array str_result to be next to the canary, starting at [ebp-10h]. When the overflow occurred, the 1-byte '\0' just occupied the 1-byte padding. Therefore it does not affect this build. When mitigation is not in place, or the string is not aligned to 4-byte, it may cause an immediate DoS (cookie corruption); or 1-byte of ebp (no stack smash protection). ------------------------------------------------------------------------ [2017-07-25 08:50:38] chiuado at gmail dot com Sorry for bothering, is this issue reproducible on windows platform? I'm using "php-5.6.30-Win32-VC11-x86", but I can not reproduce it, is there any precondition? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=74603 -- Edit this bug report at https://bugs.php.net/bug.php?id=74603&edit=1