NGINX und die OpenSSL-Sicherheitsempfehlung vom 5. Juni 2014

Welche Auswirkungen haben CVE-2014-0224 und verwandte OpenSSL-Sicherheitslücken auf NGINX?

Das OpenSSL-Projekt hat am 5. Juni 2014 Korrekturen für sieben Sicherheitslücken angekündigt. Die Einzelheiten sind in ihrem Sicherheitshinweis beschrieben.

Die Schwachstellen wirken sich möglicherweise auf jede Serveranwendung (einschließlich NGINX und NGINX Plus) aus, die OpenSSL zum Beenden des SSL/TLS-Verkehrs verwendet. Sie können ausgenutzt werden, um einen Man-in-the-Middle-Angriff (MitM) oder verschiedene Denial-of-Service-Angriffe (DoS) und Datenbeschädigungen auszulösen:

• SSL/TLS-MITM-Sicherheitslücke (CVE‑2014‑0224)
• DTLS-Rekursionsfehler (CVE‑2014‑0221)
• DTLS-Sicherheitslücke durch ungültiges Fragment (CVE‑2014‑0195)
• SSL_MODE_RELEASE_BUFFERS NULL-Zeiger-Dereferenzierung (CVE‑2014‑0198)
• SSL_MODE_RELEASE_BUFFERS-Sitzungseinschleusung oder Denial-of-Service (CVE-2010-5298)
• Anonymer ECDH-Denial-of-Service (CVE-2014-3470)
• „Andere Probleme“ (CVE‑2014‑0076)

Die Empfehlung des OpenSSL-Projektes lautet wie folgt:

Benutzer von OpenSSL 0.9.8 SSL/TLS sollten auf 0.9.8za aktualisieren. Benutzer von OpenSSL 1.0.0 SSL/TLS sollten auf 1.0.0m aktualisieren.
Benutzer von OpenSSL 1.0.1 SSL/TLS sollten auf 1.0.1h aktualisieren.

Verwendet Ihre NGINX-Installation die OpenSSL-Instanz Ihres Betriebssystemanbieters?

Von NGINX, Inc. (außer denen für Windows) oder über ein Drittanbieter-Repository bereitgestellte NGINX- und NGINX Plus-Builds werden normalerweise dynamisch mit der libssl.so -Instanz des Betriebssystems verknüpft. Führen Sie den Befehl ldd aus, um den vollständigen Pfad zur Datei libssl.so zu erfahren, und den Befehl strings , um die zugehörige Versionsnummer anzuzeigen (in diesem Fall ist es 1.0.1f):

$ ldd `which nginx` | grep ssl libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f82e62bf000) $ strings /lib/x86_64-linux-gnu/libssl.so.1.0.0 | grep "^OpenSSL " OpenSSL 1.0.1f 6. Januar 2014

Die Ausgabe auf Ihrem System kann etwas anders aussehen. Sie können auch openssl version ausführen, obwohl die Ausgabe möglicherweise nicht zuverlässig ist, wenn auf Ihrem Server mehrere Instanzen von OpenSSL vorhanden sind.

Wir empfehlen Ihnen dringend, auf die neueste OpenSSL-Bibliothek Ihres Betriebssystemanbieters zu aktualisieren, auch wenn die von Ihnen verwendete frühere Version nicht betroffen sein soll. Starten Sie dann die NGINX-Software neu, um die aktualisierte Bibliothek zu verwenden. Prüfen Sie die Antwort Ihres Anbieters auf CVE-2014-0224, um den richtigen Upgrade-Prozess zu bestimmen. Der Einfachheit halber finden Sie hier die Links für Debian , Red Hat und Ubuntu .

Bitte beachten Sie, dass einige Anbieter von Linux-Betriebssystemen korrigierte Pakete veröffentlicht haben, die noch eine frühere OpenSSL-Versionsnummer aufweisen. Sie haben sich dafür entschieden, nur den Fix für CVE-2014-0224 und verwandte Sicherheitslücken in ihre Pakete aufzunehmen, um schnell ein kleines Update bereitzustellen.

Verwendet Ihre NGINX-Installation eine statisch verknüpfte Instanz von OpenSSL?

Wenn Sie NGINX selbst kompiliert haben, haben Sie die OpenSSL-Bibliotheken möglicherweise statisch verknüpft. In diesem Fall zeigt die Ausgabe von ldd keine Abhängigkeiten von der Betriebssystembibliothek libssl.so . Führen Sie nginx -V aus, um die von Ihnen verwendeten Optionen zur Kompilierungszeit anzuzeigen:

$ ./objs/nginx -V nginx-Version: nginx/1.7.1 erstellt mit gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) Konfigurationsargumente: --with-cc-opt=-I../openssl-1.0.1f/include --with-ld-opt='-L../openssl-1.0.1f -Wl,-Bstatic -lssl -lcrypto -Wl,-Bdynamic -ldl' --with-openssl=../openssl-1.0.1f

Wenn Sie eine anfällige Version von OpenSSL verwenden, müssen Sie NGINX mit einer korrigierten Version neu kompilieren.

Verwenden Sie die NGINX-Windows-Binärdateien?

NGINX für Windows, wie von NGINX vertrieben , ist statisch mit OpenSSL verknüpft. Die aktuell verfügbaren Builds für 1.7.1 und 1.6.0 wurden mit den Fixes für OpenSSL aktualisiert.