Behebung der PHP-FPM-Sicherheitslücke (CVE-2019-11043) mit NGINX

Owen GarrettSenior Director, Produktmanagement

Eine kürzlich gemeldete Sicherheitslücke mit der Kennung CVE-2019-11043 kann Websites betreffen, die PHP‑FPM zur Ausführung von PHP-Seiten verwenden. PHP‑FPM kommt besonders häufig auf NGINX-basierten Websites zum Einsatz, da NGINX nicht über eine prozessinterne PHP-Laufzeitumgebung verfügt. Stattdessen fungiert NGINX als Reverse-Proxy für Anwendungsserver und Prozessmanager wie PHP‑FPM.

Die Schwachstelle liegt in PHP‑FPM selbst und nicht in NGINX. Die einzige garantierte Lösung besteht daher darin, auf die fehlerbereinigte Version (oder eine neuere Version) Ihrer PHP-Version zu aktualisieren: PHP 7.1.33, PHP 7.2.24 oder PHP 7.3.11.

Worin besteht die Schwachstelle?

NGINX kommuniziert mit PHP‑FPM über das FastCGI-Protokoll. Jede FastCGI-Nachricht enthält eine Reihe von Umgebungsvariablen. Eine davon, PATH_INFO, wird aus anderen Anfrageparametern abgeleitet. Wenn ihr Wert unerwartet leer ist, kann dies letztlich zu einer Speicherbeschädigung in der PHP‑FPM-Binärdatei führen. Diese Situation kann ausgenutzt werden, um die PHP‑FPM-Binärdatei dazu zu bringen, beliebige Befehle auf dem lokalen Server auszuführen.

Diese Schwachstelle kann durch eine gängige NGINX-Konfiguration ausgelöst werden, bei der NGINX einen regulären Ausdruck in der Direktive fastcgi_split_path_info verwendet, um den Anfrage-URI in zwei Teile aufzuteilen. Eine Möglichkeit, die Schwachstelle auszulösen, besteht darin, einen Zeilenumbruch (%0a) oder einen Wagenrücklauf (%0d) in den Anfrage-URI einzufügen, der dann vom regulären Ausdruck nicht korrekt verarbeitet wird.

Schutzmaßnahmen gegen die Sicherheitslücke

Wie oben erwähnt, besteht die einzige sichere Möglichkeit, diese Sicherheitslücke zu beheben, darin, auf die fehlerbereinigte Version (oder eine neuere Version) Ihrer PHP-Version zu aktualisieren: PHP 7.1.33, PHP 7.2.24 oder PHP 7.3.11.

Wenn Sie Ihre PHP-Binärdatei nicht sofort aktualisieren können, stehen Ihnen mehrere Maßnahmen zur Verfügung, mit denen sich das Risiko teilweise mindern lässt:

1. Verschiedene Quellen empfehlen, der NGINX-Konfiguration eine try_files-Direktive hinzuzufügen, um zu überprüfen, ob die Variable $uri auf eine Datei (das PHP-Skript) verweist, und die Anfrage andernfalls mit dem Statuscode 404 (Not Found) abzulehnen:

location ~ [^/]\.php(/|$) {    fastcgi_split_path_info ^(.+?\.php)(/.*)$;
    fastcgi_param           PATH_INFO $fastcgi_path_info;
    try_files               $uri =404;
    #...
}

1. Beachten Sie, dass diese Schutzmaßnahme nur funktioniert, wenn NGINX und PHP‑FPM dasselbe Dokumentenstammverzeichnis auf demselben Host verwenden. PHP-Konfigurationen unterscheiden sich je nach den Anforderungen der Upstream-Anwendung. Bitte testen Sie derartige Änderungen, um sicherzustellen, dass sie Ihre Anwendung nicht beeinträchtigen.
2. Verwenden Sie F5 BIG-IP ASM (Application Security Manager), um die Anwendung zu schützen. Die vorhandenen Signatursätze „Command Execution“ und „Server Side Code Injection“ enthalten Angriffssignaturen, die die meisten Versuche blockieren, diese PHP‑FPM-Schwachstelle zu erkennen und auszunutzen.Anmerkung der Redaktion – Seit der Veröffentlichung dieses Blogbeitrags hat das F5 Security Team eine zusätzliche Signatur veröffentlicht, die speziell auf diese Schwachstelle zugeschnitten ist. Weitere Informationen finden Sie unter F5 DevCentral.
3. Fügen Sie eine ModSecurity-Regel hinzu, um Anfragen zu blockieren, die das verdächtige Zeichen „%0a“ oder „%0d“ enthalten:

SecRule REQUEST_URI "@rx %0(a|A|d|D)" "id:1,phase:1,t:lowercase,deny"

1. Diese Lösung wird im ursprünglichen Bericht von Wallarm über die Sicherheitslücke beschrieben; sie kann zu Fehlalarmen führen, und ein Angreifer könnte dennoch andere Wege finden, die Sicherheitslücke auszunutzen.

Verwendung eines anderen PHP-Prozessmanagers

Anstatt sich auf PHP‑FPM zu verlassen, können Sie NGINX Unit verwenden, um Ihre PHP-Anwendungen auszuführen. NGINX Unit ist ein leistungsstarker Open-Source-Anwendungsserver und Prozessmanager, der neben PHP zahlreiche Sprachen und Frameworks unterstützt. Er kann PHP-Anwendungen abhängig von der Auslastung automatisch skalieren und gleichzeitig Anwendungen mit unterschiedlichen PHP-Laufzeitumgebungen ausführen. Wir stellen Binärdateien, Quellcode und Docker-Images kostenlos zur Verfügung.

In der NGINX Unit-Dokumentation finden Sie Anweisungen zur Konfiguration und zum Betrieb von NGINX Unit für WordPress, einer beliebten, stark frequentierten PHP-Anwendung. Bei der Bereitstellung wird die Unterstützung für die Bereitstellung statischer Dateien in NGINX Unit ab Version 1.11.0 genutzt.

Über den Autor

Owen GarrettSenior Director, Produktmanagement

Weitere Blogbeiträge von Owen Garrett