On 2021-06-15 10:19, Joe Watkins wrote:
It's just that existing implementation details - RETURN_CHAR using
interned
strings, and literal constant strings being interned by the compiler -
lead
to a literal string being "re-used".
This is just a natural consequence of literal strings retaining their
literalness in the way we want them too, nothing dangerous is going on.
This happens with substr as well, even with user input.
With just one character, the possibilities are rather limited, but still
I'm sure someone finds a way to turn this into a vulnerability.
Such as:
$c = substr($input, 0, 1); # $c is now literal.
$sql = "SELECT * FROM t WHERE c LIKE '$c%'";
Hopefully this "retaining literalness" does not extend to longer strings
after any operations.
What about Opcache? A few years back I debugged some interning-related
bugs which only manifested with Opcache, so I'm just thinking maybe
there's some way to exploit Opcache to make some string interned under
special circumstances, and just maybe that string can then be
accidentally reused in a SQL query. I'm not in the mood to dive into
Opcache internals to check this, so I hope someone with prior knowledge
can tell what kind of strings get interned by Opcache. Array keys?
Object properties?
--
Lauri Kenttä
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
