OpenSSL Vulnerability (CVE-2015-1793) and Remediation
A high-severity vulnerability was announced by OpenSSL. This vulnerability is marked as CVE-2015-1793. Common Vulnerabilities and Exposures is a system that provides a reference-method for publicly known security vulnerabilities and exposures. This blog explains OpenSSL Vulnerability (CVE-2015-1793) and Remediation.
OpenSSL Team released following statement regarding this vulnerability:
The OpenSSL project team would like to announce the release of OpenSSL versions 1.0.2d and 1.0.2p. These releases will be made available on 9th July. They will fix a single security defect classified as “high severity”. This defect does not affect the 1.0.0 or 0.9.8 releases.
Source: www.openssl.org
What this vulnerability can do?
It allows a user to exploit the certificate verification process in OpenSSL, allowing him/her to pretend to be another user or website.This vulnerability is a certificate verification flaw. The attacker can lure or misdirect users to a malicious website (or any internet service using TLS/SSL) and will be able to trick a user into assuming that he/she is somewhere legitimate and secure. The working of TLS/SSL relies on a “chain of trust” formed by certificates. The chain of certificates reassures the web browser that the website user is visiting really does belong to the organisation he/she expects.
The screenshot shows that we have visited google.com and it has a certificate that is verified by Google Internet Authority G2.
By selecting the “Certificate Information”, we can see more details like organization name, an expiry of the certificate and much more.
What effect does this vulnerability have on NGINX?
If we are using a configured client certificate verification in NGINX, then NGINX will use the certificate verification process in OpenSSL. This process matches a client or server certificate against a set of trusted root certificates that we provide.
Ideally, the browser should have shown a warning as in the picture above, if the certificate is either forged or not signed by any trusted root authority.
But due to this vulnerability, an attacker can make the browser to trust the certificate even if it is not signed by any trusted root authority. This will result into an attacker potentially pretending to be another user or server.
What is the possibility of this vulnerability affecting our setup?
If we are using a vulnerable version of OpenSSL, then we should upgrade the OpenSSL installation.
The version of OpenSSL used by NGINX installation can be checked as follows:
[js]
nginx -V
[/js]
In the “running with OpenSSL” statement; if it shows version as 1.0.2c, 1.0.2b, 1.0.1n or 1.0.1o (vulnerable versions). We will need to upgrade.
Upgrading OpenSSL
NGINX uses the version of OpenSSL that comes with the operating system. We need to follow OS’s instructions to update it. In our case we have ubuntu server, so we will download the package from the following link.
*The vulnerability status of operating systems other than Ubuntu are:
Source: www.nginx.com
CentOS – Not affected
Debian is affected
FreeBSD is affected
Oracle Linux – Not affected
RedHat – Not affected
SuSE – Not affected
Once we are done with upgrading the OpenSSL library, we will have to restart NGINX.
