A very interesting exploit.<p>This phrase "internally php strings are byte arrays. As a result accessing or modifying a string using array brackets will trick the parser into evaluating arbitrary php code in the scope of the variable if the prior mentioned requirements are met." doesn't seem to be present in the linked documentation (<a href="http://www.php.net/manual/en/language.types.string.php" rel="nofollow">http://www.php.net/manual/en/language.types.string.php</a>), however. Does anyone know what these "prior mentioned requirements" might be?
I'm pretty sure the error is when they later take the input and eval it, and the author's managed to dodge their filtering rather than execute arbitrary code in the context of an array-to-string cast (which I was lead to believe when reading that post, at least). Otherwise it implies that some permutation of:<p>$a = '{${phpinfo()}}';
$b = [$a];
$c = "$b";<p>Will execute phpinfo()... which it won't.
A prime example of how to deal with and educate others a vulnerability.<p>Presumably the bounty was distributed without incident which is worth noting the recent threads of bounties being forfeited.
Neat attack, I'd not seen this type before.<p>I wonder if doing "$cast = (string) $input" prior to the rest will avoid it? I do things like that, as well as making sure all methods use type hinting, which would hopefully make this harder?
More details in /r/netsec:
<a href="http://www.reddit.com/r/netsec/comments/1sqppp/ebay_remotecodeexecution/" rel="nofollow">http://www.reddit.com/r/netsec/comments/1sqppp/ebay_remoteco...</a>
All I wanted to know was whether it was the new node.js code or the old old Java systems. I click through and get a PHP exploit? Letdown.<p>Learned something though.