STRATO: Create Content - Forbidden (Error 403) - CVE-2024-38474 - UnsafeAllow3F

Michael P.

Eric Harrer
das hatte er nur am Telefon erwähnt.

pamsta

Antwort vom Support eben: Problem ist bekannt und soll heute Abend spätestens Morgen früh behoben sein.

matthaa

Ich kann das Problem bestätigen. Gerade eine Seite zu Strato überführt und es tritt exakt dieser Fehler auf. Hoffen wir auf eine rasche Lösung.

Eric Harrer

Aus dem TYPO3 Slack Channel #typo3-cms:

Update from the strato service
Wir verweisen auf Schwachstellenbeschreibung CVE-2024-38474. Dieses Update wird generell auf allen gängigen Apache Instanzen installiert werden.
Aus Sicherheitsgründen werden wir die unsichere Methode die Typo3 verwendet auf den Hostsystemen nicht wieder freigeben. Wir bitten Sie ggfs. den Entwickler von Typo3 zu Kontaktieren und Ihn auf die Schwachstelle hinzuweisen. Wir empfehlen ausdrücklich keine Modifikationen die dies umgeht umzusetzen, weil Sie dadurch angreifbar werden.

Quelle: https://typo3.slack.com/archives/C025BQLFA/p1721196291290029?thread_ts=1720944890.507609&cid=C025BQLFA

Das merkwürde daran ist, dass das Problem ja laut CVE-2024-38474 in Apache 2.4.60+ behoben ist. Benutzer berichten, dass ihre betroffenen Instanzen noch Apache 2.4.59 nutzen.

Betroffene STRATO-Kunden sollten also darum bitten, Apache zu aktualisieren.

Eric Harrer

Hier habe ich weitere Interessante Infos gefunden:
https://stackoverflow.com/questions/78729429/403-forbidden-when-url-contains-get-with-encoded-question-mark-unsafeallow3f

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[/QUOTE]

Zitat dazu von Mathias Brodala aus dem Slack Channel:

Die schlechte Version in dem Beispiel auf StackOverflow ist an sich nicht schlecht. Das Schlimme daran ist, dass es nichts gibt, was die Integrität von route / returnto sicherstellt. So kann jeder Client den Wert des Parameters manipulieren und ihn frei ändern. Dies wird normalerweise durch authentifizierte Hashes, Token usw. verhindert. Und TYPO3 tut das AFAIK. Daher ist es IMO ziemlich sinnlos, URLs mit einem verschlüsselten Fragezeichen selbst zu verweigern.

Wolfgang Wagner

Was mir jetzt nicht ganz klar ist: Würde sich das Problem durch ein Update des Apache auf 2.4.60 lösen lassen, ohne dass TYPO3 etwas ändern müsste? Oder wird das Problem erst durch einen auf 2.4.60 aktualisierten Apache verursacht?

Und auch wenn das momentan nur bei Strato aufzutreten scheint: könnte das gleiche Problem nicht bei allen Hostern auftreten, die Apache nutzen?

pamsta

Meine betroffenen Kunden haben Apache Version 2.4.59.

Eric Harrer

So, wie ich die Aussagen auf StackOverflow mittlerweile verstehe, wird das Problem nicht mit einem Update auf Apache 2.4.60 bzw. 2.4.61 wieder verschwinden. Es wäre mal interessant zu erfahren, ob es Nutzer gibt, die dieses Problem auch mit Apache 2.4.61 haben. Falls ja wird womöglich ein Austausch zwischen den Apache-Entwicklern und den verschiedenen Anwendungs-Entwicklern, wie unserem TYPO3 Core Team notwendig werden.

R-Beck

Hier die Stellungnahme von STRATO von heute:

"Sie hatten sich an uns gewendet, da Sie bei der Nutzung Ihrer Typo3 Instanz auf eine Fehlermeldung („403 Forbidden“) gestoßen sind.

Diese rührt daher, dass eine unsichere Schwachstelle durch ein Softwareupdate in der Infrastruktur geschlossen wurde. Diese hätte es Angreifern erlaubt in Ihren Webspace einzudringen und Schadcode auszuführen. Dies unterbindet die Kommunikation von Typo3 und dessen verwendeter Methode mit dem Webserver in einigen Bereichen der Typo3 Instanz.

Wir verweisen auf Schwachstellenbeschreibung CVE-2024-38474 (https://www.cve.org/CVERecord?id=CVE-2024-38474). Dieses Update wird generell auf allen gängigen Apache Instanzen installiert werden.

Aus Sicherheitsgründen werden wir die unsichere Methode die Typo3 verwendet auf den Hostsystemen nicht wieder freigeben. Wir bitten Sie ggfs. den Entwickler von Typo3 zu Kontaktieren und Ihn auf die Schwachstelle hinzuweisen. Wir empfehlen ausdrücklich keine Modifikationen die dies umgeht umzusetzen, weil Sie dadurch angreifbar werden."

Was kann man denn jetzt als Anwender konkret tun, damit man die Internetseite wieder bearbeiten kann?

Eric Harrer

Nach derzeitigem Kenntnisstand wurde die Sicherheitslücke CVE-2024-38474 in Apache 2.4.60+ so "gelöst", dass URLs mit einem kodierten Fragezeichen generell verweigert werden. Eine Praxis, die der Realität vieler Anwendungen wie TYPO3 nicht gerecht wird.

TYPO3 ist von der ursprünglichen Schwachstelle eigentlich nicht betroffen, da die URL-Integrität ohnehin durch authentifizierte Hashes, Token usw. sichergestellt wird. Demnach könnte man für TYPO3-Installationen eigentlich das Flag UnsafeAllow3F setzen, um URLs mit einem kodierten Fragezeichen wieder zu erlauben.

Aber genau das scheint STRATO derzeit nicht zuzulassen. Laut den Nutzern im Contao-Forum kommt es bei STRATO-Hostings zu einem Error 500, wenn dieses Flag gesetzt wird.

Was kannst du konkret tun? Erstmal abwarten und Tee trinken 😉

Entweder das TYPO3 Core Team hat jetzt unerwartet neue Arbeit bekommen oder Apache rudert doch noch zurück und findet eine andere Lösung für die Schwachstelle. Im Grunde kann man STRATO nicht direkt vorwerfen, dass eine offiziell als Schwachstelle gekennzeichnete Funktion nun nicht mehr zugelassen wird.

Eric Harrer

Wenn ihr wissen wollt, welche Apache Version ihr gerade nutzt geht wie folgt vor:

Debian/Ubuntu Linux

apache2 -v

CentOS/RHEL/Fedora Linux

httpd -v

Den Pfad zu apache2 bzw. httpd könnt ihr (falls verfügbar) mit type, whereis oder command finden.

type -a httpd
type -a apache2
whereis httpd
command -v httpd

In der aktuellen DDEV Version 1.23.3 sieht das beispielsweise so aus:

eric@typo3-12-project-web:~$ whereis apache2
apache2: /usr/sbin/apache2 /usr/lib/apache2 /etc/apache2 /usr/share/apache2
eric@typo3-12-project-web:~$ /usr/sbin/apache2 -v
Server version: Apache/2.4.59 (Debian)
Server built:   2024-04-05T12:02:26

Dort wird also aktuell noch die Apache Version 2.4.59 verwendet, in der wir keine Probleme haben.

Das sollten wir im Blick behalten und im Zweifel auch mit dem nächsten DDEV Update, dass eine neue Apache Version mitliefert warten, bis wir eine Lösung für TYPO3 haben.

Michael P.

Eric Harrer

mh, da kriege ich gerade etwas Bammel, denn Hetzner (und da liegt so gut wie alles was ich mit TYPO3 so gemacht habe) hat für den 18.08. ein Update der Managed Server avisiert...
Mal sehen, ob das Problem dann auch dort auftritt.

Gruß Michael

Mogens Fiebrandt

Michael P. Woher hast Du die Info zu dem Hetzner Update?
Ich konnte dazu auf offiziellen Hetzner Kanälen nichts finden.

Wolfgang Wagner

Ggf. ist es sinnvoll, die Hoster proaktiv auf das Problem hinzuweisen?

Eric Harrer

Wolfgang Wagner Ich habe Mittwald bereits diesbezüglich angeschrieben 👍

Liebes Mittwald Team,

Apache hat seit Version 2.4.60 die Sicherheitslücke CVE-2024-38474 geschlossen, indem kodierte Fragezeichen in URLs nicht mehr zugelassen werden. Dies führt im TYPO3 Backend beim Versuch neue Inhalte anzulegen beispielsweise zu dem Fehler "Forbidden (Error 403)". Auch in der Contao Community sind vergleichbare Probleme bekannt geworden.

TYPO3 selbst ist im Grunde nicht von dieser Sicherheitslücke betroffen, da dort bereits über authentifizierte Hashes, Token usw. die URL-Integrität sichergestellt wird. Aus diesem Grund stellt sich mir nun die Frage, ob das Flag "UnsafeAllow3F" künftig im Bedarfsfall gesetzt werden darf oder ob ggfls. auch im Rahmen Eurer Hostings mit Problemen auf Applikations-seite zu rechnen ist.

Vielen Dank schon mal für Eure Rückmeldung
Eric Harrer

Außerdem habe ich nun ein Ticket auf Forge dazu angelegt:
https://forge.typo3.org/issues/104410

Wolfgang Wagner

Sehr cool.

Im MIttwald Agentur-Hub hatte Sven Wappler auch schon darauf hingewiesen und Antwort erhalten.

https://agenturen.mittwald.de/index.php?r=post%2Fpost%2Fview&id=386&cguid=0a87d81a-0f25-474a-a3d2-e21f7a01f31f

Eric Harrer

So Lob ich mir das 👍

An diesem Beispiel sieht man mal, was es bedeutet, wenn ein Webhosting Provider auch auf dem Applikations-Level spezialisiert ist und dieses ernst nimmt. Jetzt habe ich das gute Gefühlt, dass meine Mittwald-Hostings voraussichtlich nicht kaputt gehen werden und dass eine vernünftige Lösung erarbeitet wird.

Michael P.

Mogens Fiebrandt

Eine Ankündigungsmail bzgl. eines meiner Managed Server. Scheint also nichts "globales" zu sein.
Gruß Michael

Wolfgang Wagner

Wie müsste das denn in der htaccess aussehen, wenn man darüber UnsafeAllow3F setzen will?

Eric Harrer

Wolfgang Wagner Wenn ich die Angaben aus dem Contao-Forum auf unsere .htaccess Datei ummünze müsste es so gehen (ungetestet):

Für den Backend-Einstiegspunkt

# in v12
RewriteRule ^typo3/(.*)$ %{ENV:CWD}typo3/index.php [QSA,L]
# in v13
RewriteRule ^typo3/(.*)$ %{ENV:CWD}index.php [QSA,L]

ändern zu

# in v12
RewriteRule ^typo3/(.*)$ %{ENV:CWD}typo3/index.php [QSA,L,UnsafeAllow3F]
# in v13
RewriteRule ^typo3/(.*)$ %{ENV:CWD}index.php [QSA,L,UnsafeAllow3F]

und für Frontend-Aufrufe

RewriteRule ^.*$ %{ENV:CWD}index.php [QSA,L]

ändern zu

RewriteRule ^.*$ %{ENV:CWD}index.php [QSA,L,UnsafeAllow3F]

« Vorherige Seite Nächste Seite »

Unterstütze das Forum

Hilf mit, den Community Hub für TYPO3 werbefrei zu halten und die Betriebskosten zu decken. Werde Official Community Hub Supporter für nur 5 Euro im Monat (zzgl. USt) und erhalte ein exklusives Supporter-Badge. Jeder Beitrag zählt!

Jetzt Supporter werden

Impressum - Datenschutz - Kontakt - Netiquette - RSS