A very interesting exploit.

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 (http://www.php.net/manual/en/language.types.string.php), however. Does anyone know what these "prior mentioned requirements" might be?

The actual quote from the manual, that they appear to be referencing, is:

Internally, PHP strings are byte arrays. As a result, accessing or modifying a string using array brackets is not multi-byte safe, and should only be done with strings that are in a single-byte encoding such as ISO-8859-1.

It seems like they just replaced:

is not multi-byte safe, and should only be done with strings that are in a single-byte encoding such as ISO-8859-1.

...with...

will trick the parser into evaluating arbitrary php code in the scope of the variable if the prior mentioned requirements are met.

But multi-byte safety is one thing, and executing arbitrary code is another.

It's still not an explanation of how you go from injecting a deformed string to executing code.

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:

$a = '{${phpinfo()}}'; $b = [$a]; $c = "$b";

Will execute phpinfo()... which it won't.

I'm not quite sure I understand it either, though this does execute phpinfo.

    $variable = "{${phpinfo()}}";
    echo "$variable is fish";

I feel I've missed the point.

This is how it is executed:

    $variable = "{${phpinfo()}}"; // <- Execution happens here
    echo "$variable is fish";

If you pass a "{${phpinfo()}}" via GET, it is not executed. The execution has to happen later - e.g. by eval() or /e.

A prime example of how to deal with and educate others a vulnerability.

Presumably the bounty was distributed without incident which is worth noting the recent threads of bounties being forfeited.

I'm impressed by eBay's quick turn-around for implementing a fix.

More details in /r/netsec: http://www.reddit.com/r/netsec/comments/1sqppp/ebay_remoteco...

Neat attack, I'd not seen this type before.

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?

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.

Learned something though.

I'm curious if corporations like ebay respond with a grateful "thank you" or rather threaten to throw you in prison?

With open arms — https://www.paypal.com/us/webapps/mpp/security-tools/reporti...

More and more, like this. In the bad old days, it was more of the latter.