Since yesterday when our Apache updated himself at night we started to get websites saying 403 Forbidden. It looks like that encoding the "?" is not anymore allowed. The crazy thing is that PHP does exactly that when using rawurlencode(). We use this for user's input in form fields which are transfered by GET. Do we need to change all this places? Using google we read about an option named "UnsafeAllow3F" but I am not sure how to set this. Has this problem occured at others and what are you doing to fix?

In the code example, in case $test contains a "?" the user get a 403 Forbidden.

<a href='test?a=<?=rawurlencode($test);?>test</a>

We managed to fix this by adding the flag UnsafeAllow3F in our rewrite rules:

[PT]

was changed to

[PT,UnsafeAllow3F]

And this fixed the issue. There is however a security vulnerability associated with this I can't seem to find much information on except for "The Apache Foundation recommends users upgrade to version 2.4.61."

I tried a manual compile and install of 2.4.61 on Ubuntu this morning, it was a bit of a nightmare and I couldn't get it working with Coldfusion in the end so am left waiting to see if they'll bring this fix to the Ubuntu package build (currently 2.4.52)

I would strongly recommend upgrading to 2.4.60+ and not using UnsafeAllow3F or UnsafePrefixStat. This is related to 2 recently discovered vulnerabilities in Apache HTTP Server. There are few details available at the moment, but they have the potential to be fairly bad.

The Issue

• https://www.cvedetails.com/cve/CVE-2024-38474/ The fix for this involved forbidding encoded question marks in URLs by default and introduced the UnsafeAllow3F flag.
• https://www.cvedetails.com/cve/CVE-2024-38475/ Discovered at the same Master of PWN event in Toronto about a week ago, also by Orange Tsai. The fix introduced UnsafePrefixStat

Now, the first one, the one that you're running into, is not in and of itself too bad. It didn't get a CVE score at all. The second one got a score of 9.1/10. Given that they were discovered at the same time, by the same person, in the same area of the code, I would bet that they are closely related and that you will be much safer if you patch both.

Other people have mentioned that there are not many details. This is good: you have time to patch. Bad news: there is a deadline for patching. Per this tweet https://x.com/orange_8361/status/1807820224659706233, Orange Tsai will be describing the vulnerabilities in a lot more detail at Black Hat, and at that point, you will see a lot more exploitation of these issues.

How to address it

The issue here is not question marks in URLs as such. It is url-encoded question marks in URLs that are used for serving static files.

Bad version:

• example.com/images?route=/cats/long-hair%3fsize=large
• example.com/login?returnto=/cats/long-hair%3fsize=large

Good versions:

• example.com/images/cats/long-hair?size=large
• example.com/login?returnto=/cats/long-hair&returntoparams=size%3dlarge

Changing all instances of this may be a pain. Security is like that, I'm sorry. But these vulnerabilities are low-complexity, relatively high impact, and about to be documented publicly in a lot more detail. I would not want to be vulnerable if someone decides that these are good bugs for mass exploitation.

To fix this, change your rewrite rules from this:

RewriteRule Pattern Substitution
RewriteRule Pattern Substitution [flags]

to this:

RewriteRule Pattern Substitution [UnsafeAllow3F]
RewriteRule Pattern Substitution [flags,UnsafeAllow3F]

References:

UnsafeAllow3F Apache documentation

USN-6885-1: Apache HTTP Server vulnerabilities (mod_rewrite)

I saw errors like "AH10508: Unsafe URL with %3f URL rewritten without UnsafeAllow3F" in the Apache error log on AlmaLinux starting 7/11/2024, and the above fixed it.

Experiencing the same issue here within Wordpress where attempting to modify a record that exists in a paginated area (page 2 and beyond - e.g. users) returns a Forbidden 403 error. Despite the above suggestions with modifying existing RewriteRules in htaccess, virtual hosts file or even apache config itself, the problem persists which is causing chaos.

Running apache 2.4.61.

Is there a way to enable the UnsafeAllow3F flag globally, as opposed to each individual rule?

As stated in Apache's documentation this flag is only necessary if the rewrite target contains ?:

Setting this flag is required to allow a rewrite to continue If the HTTP request being written has an encoded question mark, '%3f', and the rewritten result has a '?' in the substitution. This protects from a malicious URL taking advantage of a capture and re-substitution of the encoded question mark.

An example would be

RewriteRule ^ index.php?x [L]

But if you have something equivalent to

RewriteRule ^ index.php [L]

to rewrite all requests to your PHP application (like in symfony/apache-pack's default .htaccess) you will not need the UnsafeAllow3F flag and URLs like /login?redirect=/lorem%3Ffoo=bar will continue to work as normal.

However, certain hosters (like Strato) did have a RewriteRule directive with a ? URL substitution in the general Apache configuration in their shared hosting setups. They have since rectified the issue (to some degree - URLs like /%3F are still disallowed).

Keep in mind that even if a RewriteRule containing a ? in their substitution would not apply - they are still evaluated by Apache in order and thus can cause the 403 response.