NGINX and the 5 June 2014 OpenSSL Security Advisory

What is the Impact on NGINX of CVE‑2014‑0224 and Related OpenSSL Vulnerabilities?

The OpenSSL project announced fixes to seven security vulnerabilities on 5 June 2014. The details are described in their Security Advisory.

The vulnerabilities potentially affect any server application (including NGINX and NGINX Plus) that uses OpenSSL to terminate SSL/TLS traffic. They can be exploited to create a man‑in‑the‑middle (MitM) attack or a variety of denial‑of‑service (DoS) and data corruption issues:

• SSL/TLS MITM vulnerability (CVE‑2014‑0224)
• DTLS recursion flaw (CVE‑2014‑0221)
• DTLS invalid fragment vulnerability (CVE‑2014‑0195)
• SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE‑2014‑0198)
• SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE‑2010‑5298)
• Anonymous ECDH denial of service (CVE‑2014‑3470)
• “Other Issues” (CVE‑2014‑0076)

The recommendation from the OpenSSL project is as follows:

OpenSSL 0.9.8 SSL/TLS users should upgrade to 0.9.8za.OpenSSL 1.0.0 SSL/TLS users should upgrade to 1.0.0m.
OpenSSL 1.0.1 SSL/TLS users should upgrade to 1.0.1h.

Does Your NGINX Installation Use Your OS Vendor’s Instance of OpenSSL?

NGINX and NGINX Plus builds provided by NGINX, Inc. (except those for Windows) or through a third‑party repository are usually dynamically linked to the operating system’s instance of libssl.so. Run the ldd command to learn the full path to the libssl.so file and the strings command to display the associated version number (in this case, it’s 1.0.1f):

$ ldd `which nginx` | grep ssllibssl.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 Jan 2014

Output on your system might look somewhat different. You can also run openssl version, although the output might not be reliable if there are several instances of OpenSSL on your server.

We strongly recommend that you upgrade to the most recent OpenSSL library provided by your operating system vendor, even if the earlier version you are running is not reported to be affected. Then restart the NGINX software to use the updated library. Check your vendor’s response to CVE-2014-0224 to determine the correct upgrade process. For your convenience, here are the links for Debian, Red Hat, and Ubuntu.

Please note that some Linux operating system vendors have released fixed packages that still bear an earlier OpenSSL version number, electing to include just the fix for CVE‑2014‑0224 and related vulnerabilities in their packages in order to provide a small update quickly.

Does Your NGINX Installation Use a Statically Linked Instance of OpenSSL?

If you have compiled NGINX yourself, you might have statically linked the OpenSSL libraries. In this case the output from ldd does not reveal dependencies on the operating system libssl.so library. Run nginx ‑V to display the compile‑time options you used:

$ ./objs/nginx -V
nginx version: nginx/1.7.1

built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

configure arguments: --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

If you are using a vulnerable version of OpenSSL, you need to recompile NGINX using a corrected version.

Are You Using the NGINX Windows Binaries?

NGINX for Windows, as distributed by NGINX, is statically linked with OpenSSL. The currently available builds for 1.7.1 and 1.6.0 have been updated with the fixes to OpenSSL.