NGINX setzt sich weiterhin für die Sicherheit von Benutzern in Aktion ein

F5 NGINX setzt sich für einen sicheren Software-Lebenszyklus ein, einschließlich Design, Entwicklung und Tests, die darauf ausgelegt sind, Sicherheitsbedenken vor der Veröffentlichung zu erkennen. Obwohl wir großen Wert auf Bedrohungsmodellierung, sichere Codierung, Schulung und Tests legen, treten gelegentlich Schwachstellen auf.

Letzten Monat meldete ein Mitglied der NGINX Open Source-Community zwei Fehler im HTTP/3-Modul, die einen Absturz in NGINX Open Source verursachten. Wir haben festgestellt, dass ein böswilliger Akteur durch das Senden speziell gestalteter HTTP/3-Anfragen einen Denial-of-Service-Angriff auf NGINX-Instanzen durchführen könnte. Aus diesem Grund hat NGINX gerade zwei Schwachstellen bekannt gegeben: CVE-2024-24989 und CVE-2024-24990 .

Die Schwachstellen wurden in der CVE-Datenbank (Common Vulnerabilities and Exposures) registriert und das F5 Security Incident Response Team (F5 SIRT) hat ihnen anhand der Skala des Common Vulnerability Scoring System (CVSS v3.1) Punkte zugewiesen.

Bei der Veröffentlichung galten die QUIC- und HTTP/3-Funktionen in NGINX als experimentell. Bisher haben wir für experimentelle Funktionen keine CVEs herausgegeben, sondern den entsprechenden Code gepatcht und als Teil einer Standardversion veröffentlicht. Für kommerzielle Kunden von NGINX Plus würden die beiden vorherigen Versionen gepatcht und an die Kunden weitergegeben. Wir waren der Meinung, dass es unserer Community keinen guten Dienst tun würde, wenn wir keinen ähnlichen Patch für NGINX Open Source herausgeben würden. Darüber hinaus hätte das Beheben des Problems im Open-Source-Zweig die Benutzer der Sicherheitsanfälligkeit ausgesetzt, ohne dass eine Binärdatei bereitgestellt worden wäre.

Unsere Entscheidung, einen Patch sowohl für NGINX Open Source als auch für NGINX Plus zu veröffentlichen, basiert auf der Absicht, das Richtige zu tun – unseren Kunden und der Community hochsichere Software bereitzustellen. Darüber hinaus verpflichten wir uns, eine klare Richtlinie zur zeitnahen und transparenten Behebung zukünftiger Sicherheitslücken zu dokumentieren und zu veröffentlichen.