NGINX schließt Lücken, durch die Angreifer ohne Login Code auf Servern ausführen können

NGINX hat am 14. Oktober die Versionen 1.30.6 (stable) und 1.31.7 (mainline) veröffentlicht und damit fünf Schwachstellen behoben. Bei dreien handelt es sich um Speicherfehler, die ein Angreifer mit präparierten HTTP-Anfragen und ohne Anmeldung auslösen kann. Im schlimmsten Fall führt das zur Ausführung von Code auf dem Server. F5, der Entwickler von NGINX, bewertet diese drei Lücken nach CVSS 4.0 mit 9.2 von 10 Punkten (kritisch). Jede der drei ist jedoch nur mit einer bestimmten Konfiguration erreichbar, ein Server mit NGINX ist also nicht automatisch betroffen. Nach Angaben von F5 gibt es weder einen öffentlichen Exploit noch bekannte Angriffe.

Was behoben wurde

Die drei schwerwiegenden Fehler hängen von Direktiven ab, die in echten Konfigurationen häufig vorkommen:

In den ersten drei Fällen bringt der Überlauf einen NGINX-Worker-Prozess zum Absturz, der danach neu startet. Wiederholte Anfragen können das beliebig oft auslösen, im Mindestfall ist es also ein Denial-of-Service. Codeausführung ist laut F5 auf Systemen möglich, auf denen die Adressraum-Zufallsverteilung (ASLR) abgeschaltet ist oder der Angreifer sie umgehen kann. Der Fehler bei alias steckt seit Version 0.1.29 im Code, die 2005 erschien.

Der Fehler bei den Session-Tickets ist anderer Art. Einer der rotierten Schlüssel wurde nicht initialisiert, und laut F5 könnte ein Angreifer damit eine TLS-Sitzung fälschen und die Prüfung von Client-Zertifikaten umgehen. Das betrifft Server, die Nutzer per Zertifikat zulassen, etwa Admin-Oberflächen und interne Dienste.

Kritisch oder mittel?

Die beiden Einstufungen wirken widersprüchlich. Auf der Advisory-Seite von nginx.org sind alle fünf Fehler als "medium" markiert. In den eigenen CVE-Einträgen von F5 erhalten die drei Speicherfehler 9.2 nach CVSS 4.0 und 8.1 (hoch) nach CVSS 3.1. Der Unterschied liegt in den Voraussetzungen. Der CVSS-Vektor besagt, dass der Angriff kein Konto braucht, aber hohe Komplexität hat, weil er nur bei passender Konfiguration funktioniert. Security Affairs schrieb am 16. Oktober über elf behobene Probleme. Die höhere Zahl umfasst mehr als NGINX selbst: Am selben Tag lieferte F5 Updates für verwandte Produkte aus, darunter das Skriptmodul njs, den Ingress Controller und Gateway Fabric.

So prüfen Sie den eigenen Server

NGINX läuft vor vielen selbst gehosteten Diensten auf gemieteten Servern, etwa vor VPN- und Proxy-Panels, Dateifreigaben und kleinen Websites. Wer so einen Server betreibt, kommt für den Anfang mit zwei Befehlen aus. nginx -v zeigt die Version, und nginx -T | grep -nE 'alias|request_filename|aio|ssi |ssl_session_cache|ssl_session_ticket|map ' listet die Direktiven aus der Tabelle in der gesamten geladenen Konfiguration auf.

Die Versionsnummer allein kann in die Irre führen. Debian und Ubuntu behalten ältere NGINX-Versionen bei und spielen Sicherheitspatches darauf ein, deshalb sagt "1.22" oder "1.26" auf einem Server nichts darüber, ob die Oktober-Korrekturen enthalten sind. Am 17. Oktober führte der Debian Security Tracker die Pakete für bookworm und trixie noch als verwundbar. Prüfen Sie den Tracker Ihrer Distribution und aktualisieren Sie mit apt update && apt upgrade, sobald ein korrigiertes Paket erscheint. Bei den offiziellen Paketen von nginx.org sind die behobenen Versionen 1.30.6 und 1.31.7.

Bis zum Update rät F5 zu Änderungen an der Konfiguration: alias und $request_filename in betroffenen Locations vermeiden, in der map benannte Captures statt $1 und $2 verwenden, aio abschalten oder keine SSI-Seiten mehr ausliefern, und Ticket-Schlüssel entweder per ssl_session_ticket_key aus einer Datei laden oder Tickets mit ssl_session_tickets off ausschalten. Unsere Anleitung zur Absicherung eines VPS behandelt den Rest der grundlegenden Server-Hygiene.