Fix CVE-2024-4577 for Caddy

[devil1591 (Rob)]

Following the criticity of this exploit, maybe you should communicate with a fix for this?

:80 {
    @blockAd {
        query ^%ad
    }
    rewrite @blockAd /forbidden
    respond /forbidden 403 {
        close
    }
}

[francislavoie]

My understanding is this is only an issue on Windows servers using PHP-CGI, and only when the Windows machine is using a Chinese or Japanese locale. Not servers with PHP-FPM/FastCGI. The impact is extremely low.

Just upgrade your PHP version. This doesn’t have anything to do with Caddy.

[matt (Matt Holt)]

Thanks for sharing the workaround for Caddy users! LGTM.

[ejin (Nothing)]

Good advice. Although the impact range is not large, the risk brought by this security vulnerability is not small.

The affected PHP version range:
8.0 version and below
8.1.0-8.1.28
8.2.0-8.2.19
8.3.0-8.3.7

[ejin (Nothing)]

@francislavoie

In the community I often visit, many administrators reported that they were affected and the server data was encrypted.

Although it has nothing to do with caddy, the old version of PHP has been abandoned. It is not convenient to upgrade the PHP program to the latest 8.X (syntax is incompatible, functions are abandoned), no one is willing to refactor their own programs, and third-party libraries must be repaired. Many people who use third-party programs are even less capable of upgrading.

So I think it just has a smaller impact, but the severity is not small.

It is of great significance to solve this security vulnerability through caddy.

[francislavoie]

@ejin are you really running a website in production on Windows, using php-cgi (e.g. XAMPP), with a locale like Japanese or Chinese?

If so, the solution is obvious. Move to Linux. Or change your Windows locale to English for that server. Or upgrade PHP (I realize you say that’s complicated but it can be done).

There’s really so many problems with using XAMPP and php-cgi for production. It was designed for development, not for production use.

[ejin (Nothing)]

Thank you for the advice. Fortunately, my server was not affected. Although I also use an older version of PHP, it’s for command-line programming, as an alternative to Python.

In my experience, different people have different environments, and each has their reasons. Changing the operating system language or switching operating systems is often not feasible for them. For example, a company may not have a spare server. I think they will be affected because they are not capable of doing much about it. The most effective way is still to patch the vulnerability, which won’t cause any impact.

Maybe I went off topic, but after careful consideration, I’ll rephrase my thoughts.

1. What I hope is that Caddy is not within the affected range. My point is that using Caddy to run PHP on Windows won’t be affected. In this case, the actual effect of this post is not significant, and adding rules would only decrease performance (although the impact is negligible). I plan to try it out when I have time.
2. Recently, I’ve searched for many articles and hope to locate the relevant code snippets from the PHP source code, targeting several key versions (e.g., PHP 5.6, 7.4, 8.0), to patch the vulnerability directly and release it. I haven’t succeeded yet because I don’t know C++ and my native language is not English, making it harder to find resources. I’ll take it slow, and I’m also looking forward to others with similar ideas to achieve it first.