* Erik Auerswald: > Hi, > > On Mon, May 27, 2024 at 12:31:46PM +0200, Florian Weimer wrote: >> > >> > Although very late, here is a follow up explaining the impact of the >> > vulnerability. >> > >> > Provided that you can force an application to convert a partially >> > controlled buffer to ISO-2022-CN-EXT, you get an >> > overflow of 1 to 3 bytes whose value you don't control. >> > >> > This can be triggered in at least two ways in PHP: >> > >> > - Through direct calls to iconv() >> > - Through the use of PHP filters (i.e. using a "file read" vulnerability) >> > >> > Due to the way PHP's heap is built, you can use such a memory >> > corruption to alter part of a free list pointer, >> > which can in turn give you an arbitrary write primitive in the >> > program's memory. >> > >> > With this bug, any person that has a file read vulnerability with a >> > controlled prefix on a PHP application has RCE. >> >> Out of curiosity, why would PHP translate a file to ISO-2022-CN-EXT >> while reading it? It's not even an ASCII-transparent charset. > > According to <https://www.ambionics.io/blog/iconv-cve-2024-2961-p1>, PHP > can be told to do so via "php://filter/…", a default behavior of PHP, > it seems (I have just skimmed that page and do not know any details).
Oh, right: | Obviously, base64-encoding is not the only thing you can do. Many | filters are available. | […] | | » convert.iconv.X.Y, which converts charset from X to Y | | Let's take a look at the last filter: convert.iconv.X.Y. Say that I need | to convert my file from UTF8 to UTF16. I can use: | | php://filter/convert.iconv.UTF-8.UTF-16/resource=/etc/passwd Unfortunately, that exposes all installed iconv converters in all directions (unlike glibc's ,ccs= parameter for fopen), once there is an arbitrary URL read injection vulnerability in a PHP application. Thanks, Florian
