F5 NGINX setzt sich für einen sicheren Softwarelebenszyklus ein, der Design, Entwicklung und Tests umfasst, die darauf optimiert sind, Sicherheitsprobleme bereits vor der Veröffentlichung zu erkennen. Obwohl Bedrohungsmodellierung, sichere Programmierung, Schulungen und Tests für uns höchste Priorität haben, können gelegentlich dennoch Schwachstellen auftreten.
Letzten Monat meldete ein Mitglied der NGINX Open Source-Community zwei Fehler im HTTP/3-Modul, die zum Absturz von NGINX Open Source führten. Wir stellten fest, dass ein Angreifer durch das Senden speziell präparierter HTTP/3-Anfragen einen Denial-of-Service-Angriff auf NGINX-Instanzen auslösen könnte. Aus diesem Grund hat NGINX soeben zwei Sicherheitslücken bekannt gegeben: CVE-2024-24989 und CVE-2024-24990.
Die Schwachstellen wurden in der Common-Vulnerabilities-and-Exposures-Datenbank (CVE) registriert und das F5 Security Incident Response Team (F5 SIRT) hat sie anhand der Skala des Common Vulnerability Scoring System (CVSS v3.1) bewertet.
Bei ihrer Veröffentlichung galten die QUIC- und HTTP/3-Funktionen in NGINX als experimentell. In der Vergangenheit haben wir für experimentelle Funktionen keine CVEs veröffentlicht, sondern stattdessen den betreffenden Code korrigiert und die Korrektur im Rahmen einer regulären Version bereitgestellt. Für kommerzielle Kunden von NGINX Plus wurden jeweils die beiden vorherigen Versionen korrigiert und den Kunden zur Verfügung gestellt. Wir waren der Ansicht, dass es unserer Community gegenüber unfair wäre, keinen vergleichbaren Patch für NGINX Open Source bereitzustellen. Zudem hätte eine Behebung des Problems im Open-Source-Zweig die Benutzer auf die Schwachstelle aufmerksam gemacht, ohne ihnen eine Binärdatei zur Verfügung zu stellen.
Unsere Entscheidung, einen Patch sowohl für NGINX Open Source als auch für NGINX Plus zu veröffentlichen, beruht auf unserem Anspruch, das Richtige zu tun – nämlich unseren Kunden und der Community hochsichere Software bereitzustellen. Darüber hinaus verpflichten wir uns, klare Richtlinien zu dokumentieren und zu veröffentlichen, die festlegen, wie künftige Sicherheitslücken zeitnah und transparent behoben werden.
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.