Full Report
Orange Tsai (of course) found a vulnerability within PHP. In particular, they found an issue that affects XAMPP (a popular way for admins to deploy PHP apps) to get RCE. The original post did not have many details about the bug itself. So, the author of this post started to dig into the issue. They noticed that it only affected CGI mode of PHP. When doing this, it parses HTTP requests and passes them to a PHP script to do processing. For instance, http://host/cgi.php?foo=bar turns into php.exe cgi.php foo=bar. Naturally, you would think this is an obvious command injection vector for calling php.exe. In fact, CVE-2012-1823 was exactly this bug! The original bug was an issue in a URL lacks the = character between parameters, the data wasn't being properly encoded. What's the new bug? Of course, it's Unicode! When PHP does processing on the input parameters, it will do best fit mapping of characters. This is crazy, as mapping unicode to ASCII feels impossible. In the CGI code for preventing command injection, it will escape hyphens to prevent extra parameters from being specified. However, a soft hyphen (0xAD) does not get escaped but PHP will convert this to a regular hyphen! Hence, we can add in our own parameters. The actual exploit is hilariously simple. Make an HTTP request with %AD (soft hyphen) to smuggle in a dash. Now, we can control arbitrary parameters to PHP. Using the -d flag to control PHP configurations. Setting auto_prepend_file=php://payload alongside the allow_url_include flag to enable PHP URLs allows us to get code execution on the server. The normalization code from unicode to ASCII was weird to me. I've read reports about this for years but have never seen anything actually do it. Apparently, unicode has a standard for normalization, where this is a Python implementation as well. The bug is exploitable on a few different locales, which is fascinating. To me, there are two main takeaways. First, old bugs are good to know; many of the attack vectors from them are there. With new progression in security techniques, more bugs in these areas may fall out. Second, Unicode to ASCII things exist. Overall, great bug!
Analysis Summary
# Vulnerability: PHP-CGI Argument Injection (CGI Mode)
## CVE Details
- **CVE ID:** CVE-2024-4577
- **CVSS Score:** 9.8 (Critical)
- **CWE:** CWE-212 (Improper Cross-boundary Removal of Relevant Operands) / CWE-74 (Injection)
## Affected Systems
- **Products:** PHP, XAMPP (default installations on Windows)
- **Versions:**
- PHP 8.3 < 8.3.8
- PHP 8.2 < 8.2.20
- PHP 8.1 < 8.1.29
- All versions of PHP 8.0, 7.x, and 5.x (End-of-Life)
- **Configurations:**
- Windows OS specifically.
- PHP running in **CGI mode** (or through XAMPP’s default configuration).
- Systems set to specific locales: Chinese (Simplified/Traditional) and Japanese. Other locales are potentially vulnerable but unconfirmed.
## Vulnerability Description
The flaw stems from a "Best Fit" character encoding mapping during Unicode-to-ASCII conversion on Windows. When PHP is used in CGI mode, the web server (Apache) identifies and escapes specific characters like the hyphen (0x2D) to prevent command-line argument injection.
However, Windows' character normalization maps the "Soft Hyphen" (`0xAD`) to a standard hyphen (`0x2D`). Because the security filter only looks for the literal ASCII hyphen, the soft hyphen passes through unescaped. When the input reaches the PHP interpreter, the OS/PHP normalization converts `0xAD` back into a functional command-line delimiter (`-`), allowing an attacker to inject arbitrary PHP configuration arguments.
## Exploitation
- **Status:** PoC available and exploited in the wild.
- **Complexity:** Low
- **Attack Vector:** Network
## Impact
- **Confidentiality:** High (Full data access via RCE)
- **Integrity:** High (System modification via RCE)
- **Availability:** High (System takeover or shutdown)
## Remediation
### Patches
Users should upgrade to the following versions:
- PHP 8.3.8 or later
- PHP 8.2.20 or later
- PHP 8.1.29 or later
### Workarounds
- **Disable CGI Mode:** Transition from PHP-CGI to more modern and secure alternatives such as FastCGI, PHP-FPM, or Apache's `mod_php`.
- **Rewrite Rules:** For users unable to patch immediately, use Mod_Rewrite to block malicious queries (Note: This is locale-specific and less reliable than patching):
`RewriteCondition %{QUERY_STRING} ^.*%ad.* [NC]`
`RewriteRule .? - [F,L]`
## Detection
- **Indicators of Compromise:** HTTP POST or GET requests containing `%AD` followed by PHP arguments (e.g., `%ADd`, `allow_url_include`, `auto_prepend_file`).
- **Detection Methods:** Monitor web server logs for suspicious query strings targeting `php-cgi.exe` or `.php` endpoints with smuggled arguments. Inspect for `php://input` or `php://payload` in the query parameters.
## References
- **Vendor Advisory:** hxxps[://]www[.]php[.]net/archive/2024[.]php#2024-06-06-1
- **Original Research:** hxxps[://]devco[.]re/blog/2024/06/06/security-alert-cve-2024-4577-php-cgi-argument-injection-vulnerability-en/
- **Analysis:** hxxps[://]labs[.]watchtowr[.]com/no-way-php-strikes-again-cve-2024-4577/