5 ms·

I wonder what the PHP specific part is. Does it automatically convert the encoding based on a request header?

smsm42 2y ago
I seriously doubt you can make PHP convert anything to that exotic charset automatically even with creative configuration, and pretty much sure it wouldn't do any of the sort in common configuration. What I suspect is going on is that the author is interested in exploiting PHP engine and is assuming PHP code using iconv() and wants to talk about how to get from there to full scale RCE. It is indeed a fascinating and non-trivial topic, though the relationship between a particular CVE and the PHP angle is rather coincidental - any buffer overflow would do, it's just the author happened to have one in a reasonably common function.
fweimer 2y ago
That's the other direction (legacy charset conversion to UCS-4 or UTF-8). This other direction is often reachable using the charset parameter in the Content-Type header and similar MIME contexts. HTTP theoretically supports Accept-Charset, but it's deprecated: https://www.rfc-editor.org/rfc/rfc9110.html#name-accept-charset https://www.rfc-editor.org/rfc/rfc9110.html#name-accept-char... But I think on-the-fly charset conversion in the web server is quite rare. Apache httpd does not seem to implement it: https://httpd.apache.org/docs/2.4/content-negotiation.html#methods https://httpd.apache.org/docs/2.4/content-negotiation.html#m... The charset in question does not have a locale associated with it (it's not even ASCII-transparent), so I don't think it's usable in a local context together with SUID/SGID/AT_SECURE programs.
lyu07282 2y ago
My guess is, it's application specific, php applications that use the iconv function in some specific way, in some specific context, will be vulnerable. https://www.php.net/manual/en/function.iconv.php https://www.php.net/manual/en/function.iconv.php
pengaru 2y ago
Your comment knocked loose a long dormant memory https://en.wikipedia.org/wiki/Magic_quotes https://en.wikipedia.org/wiki/Magic_quotes

I seriously doubt you can make PHP convert anything to that exotic charset automatically even with creative configuration, and pretty much sure it wouldn't do any of the sort in common configuration. What I suspect is going on is that the author is interested in exploiting PHP engine and is assuming PHP code using iconv() and wants to talk about how to get from there to full scale RCE. It is indeed a fascinating and non-trivial topic, though the relationship between a particular CVE and the PHP angle is rather coincidental - any buffer overflow would do, it's just the author happened to have one in a reasonably common function.

fweimer 2y ago

That's the other direction (legacy charset conversion to UCS-4 or UTF-8). This other direction is often reachable using the charset parameter in the Content-Type header and similar MIME contexts. HTTP theoretically supports Accept-Charset, but it's deprecated: https://www.rfc-editor.org/rfc/rfc9110.html#name-accept-charset https://www.rfc-editor.org/rfc/rfc9110.html#name-accept-char... But I think on-the-fly charset conversion in the web server is quite rare. Apache httpd does not seem to implement it: https://httpd.apache.org/docs/2.4/content-negotiation.html#methods https://httpd.apache.org/docs/2.4/content-negotiation.html#m... The charset in question does not have a locale associated with it (it's not even ASCII-transparent), so I don't think it's usable in a local context together with SUID/SGID/AT_SECURE programs.

lyu07282 2y ago

My guess is, it's application specific, php applications that use the iconv function in some specific way, in some specific context, will be vulnerable. https://www.php.net/manual/en/function.iconv.php https://www.php.net/manual/en/function.iconv.php

pengaru 2y ago

Your comment knocked loose a long dormant memory https://en.wikipedia.org/wiki/Magic_quotes https://en.wikipedia.org/wiki/Magic_quotes