NGINX.COM
Web Server Load Balancing with NGINX Plus

Are NGINX and NGINX Plus Vulnerable to the Heartbleed Vulnerability in OpenSSL?

The Heartbleed bug (see heartbleed.com and the OpenSSL advisory) is a serious vulnerability in the popular OpenSSL cryptographic software library, announced on April 7,  2014. It allows access to up to 64 KB of internal memory in affected servers, which potentially exposes sensitive information including SSL private keys.

The bug was introduced in OpenSSL 1.0.1, and is resolved in version 1.0.1g and later. If your NGINX version or NGINX Plus release uses an affected version of OpenSSL, you must upgrade your OpenSSL library immediately and verify that your NGINX and NGINX Plus instances are using the updated version.

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

NGINX builds provided by NGINX, Inc. 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 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 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-0160 to determine the correct upgrade process. For your convenience, here are the links for Red Hat and Ubuntu.

Please note that some Linux operating system vendors have released fixed packages that still bear the OpenSSL 1.0.1e version number. Even though the OpenSSL project released 1.0.1g as their newest software, downstream Linux providers have in some cases elected to include just the fix for CVE-2014-0160 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.5.11
 
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, recompile NGINX with a fixed version, or recompile OpenSSL using the -DOPENSSL_NO_HEARTBEATS option and then recompile NGINX.

Hero image
Are Your Applications Secure?

Learn how to protect your apps with NGINX and NGINX Plus



About The Author

Owen Garrett

Sr. Director, Product Management

Owen is a senior member of the NGINX Product Management team, covering open source and commercial NGINX products. He holds a particular responsibility for microservices and Kubernetes‑centric solutions. He’s constantly amazed by the ingenuity of NGINX users and still learns of new ways to use NGINX with every discussion.

About F5 NGINX

F5, Inc. is the company behind NGINX, the popular open source project. We offer a suite of technologies for developing and delivering modern applications. Together with F5, our combined solution bridges the gap between NetOps and DevOps, with multi-cloud application services that span from code to customer.

Learn more at nginx.com or join the conversation by following @nginx on Twitter.