Broken Websites after Apache Update: UnsafeAllow3F – A game you cannot win

Since July 9 2024, Apache 2.4.60 has been released and brings a security update which solves CVE-2024-38474 but apperantly breaks a lot of web pages, including software that is written with TYPO3 framework.

The update however is a disaster. And I will explain why:

The patch in apache will throw a 403 Forbidden for every rewritten URL that contains %3F encoded in a URL. The reason for that is that attackers could smuggle in „?“ queries and trick some CGI scripts to access files the user shouldn’t have permission to. For more info, read https://nvd.nist.gov/vuln/detail/CVE-2024-38474

To further allow intended use, e.g. in back-URLs (e.g. returnto= in TYPO3), Apache added the UnsafeAllow3F option in your .htaccess rules. And there lies the problem: Before Apache 2.4.60, the option was unknown and led to a 500 Internal Server Error.

Here’s an overview schema of the dilemma:

	Apache 2.4.59 or older	Apache 2.4.60 or newer
Hacker attack with %3F	vulnerable	fixed
Intended use of %3F	works	403 Forbidden
Use option UnsafeAllow3F	500 Internal Server Error	works

Since you cannot write conditional .htaccess files, it is currently not possible to write software that both works on Apache 2.4.59 and 2.4.60.

So what is this? Why does Apache forbid a certain letter in the alphabet to fix vulnerable scripts??

This reminds me of Magic Quotes from 1997. Magic Quotes is a deprecated PHP extension that tried to fix SQL Injections in vulnerable PHP scripts by quoting all input strings. This led to the problem that you weren’t allowed to encode certain strings into your input any more. And on top of it, this didn’t solve the issue as well since new SQL injection techniques arose that evaded this security mechanism.

Here’s an example:

<?php
$db->query("SELECT * FROM users WHERE username = '" . $_GET['username'] . "'"); // do not try this at home

The way a SQL injection works is to put something like ' OR TRUE -- into $_GET['username'] and this way, the string coming from user input will be ended by ' and the attacker is able to inject SQL code.

Magic Quotes tried to solve this by replacing all ' by \' which solved the problem in some cases but at the same time broke existing programs and introduced additional vulnerabilities.

Magic Quotes were officially deprecated as of PHP 5.3.0 and removed in PHP 5.4, due to security concerns. It is the perfect example of a software that tries to solve a problem that can only be fixed by the user. Why does Apache repeat this design mistake 27 years later?