diff --git a/locale/en/blog/vulnerability/openssl-march-2016.md b/locale/en/blog/vulnerability/openssl-march-2016.md index f2293a0a42bb3..371a1e6308711 100644 --- a/locale/en/blog/vulnerability/openssl-march-2016.md +++ b/locale/en/blog/vulnerability/openssl-march-2016.md @@ -7,6 +7,8 @@ layout: blog-post.hbs author: Rod Vagg --- +***(Updates to this post, including a schedule change are included below)*** + The OpenSSL project has [announced](https://mta.openssl.org/pipermail/openssl-announce/2016-February/000063.html) that that they will be releasing versions 1.0.2g and 1.0.1s this week, on **Tuesday the 1st of March, UTC**. The releases will fix _"several defects"_ that are labelled as _"high"_ severity under their security policy, meaning they are: > ... issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable. @@ -64,3 +66,73 @@ The current Node.js security policy can be found at Modern servers and clients use the TLS encryption protocol. However, due to misconfigurations, many servers also still support SSLv2, a 1990s-era predecessor to TLS. This support did not matter in practice, since no up-to-date clients actually use SSLv2. Therefore, even though SSLv2 is known to be badly insecure, until now, merely supporting SSLv2 was not considered a security problem, because clients never used it. + +> DROWN shows that merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key. + +It is important to note that simply supporting SSLv2 on an HTTPS socket enables this vulnerability, regardless of whether clients are actively using SSLv2. + +Since Node.js v0.10.29, SSLv2 and SSLv3 have been disabled by default. It has remained possible to enable them with the `--enable-ssl2` and `--enable-ssl3` command-line arguments to `node`. As these protocols have consistently been demonstrated to be insecure, keeping SSLv2 and SSLv3 disabled has been strongly encouraged. + +If you are using the `--enable-ssl2` command-line argument with `node` then HTTPS servers are vulnerable to this attack. You should stop using this argument to avoid potential decryption of your secure data. + +**SSLv2 support is being removed** + +Given the additional barriers introduced in OpenSSL 1.0.1s to retaining SSLv2 support and the long list of known SSLv2 vulnerabilities, Node.js v0.10.43 and v0.12.11 will be completely remove SSLv2 support and the `--enable-ssl2` command-line argument. + +### [CVE-2016-0705](https://www.openssl.org/news/vulnerabilities.html#2016-0705): Fix a double-free in DSA code + +**Assessment**: All versions of Node.js **are affected**, with low severity + +This defect allows the use of malformed DSA to be used as a potential Denial of Service (DoS) vector or for causing memory corruption. However it is likely to be very difficult to use in practice and is therefore considered low severity for Node.js users. + +### [CVE-2016-0798](https://www.openssl.org/news/vulnerabilities.html#2016-0798): Disable SRP fake user seed to address a server memory leak + +**Assessment**: All versions of Node.js **are unaffected** + +The [Secure Remote Password (SRP)](https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol) feature of OpenSSL is not exposed via Node.js, therefore all versions are unaffected by this defect. + +### [CVE-2016-0797](https://www.openssl.org/news/vulnerabilities.html#2016-0797): Fix BN_hex2bn/BN_dec2bn NULL pointer deref/heap corruption + +**Assessment**: All versions of Node.js **may be affected**, with low severity + +This defect can cause memory corruption in certain very rare cases. Additionally, the `BN_hex2bn()` and `BN_dec2bn()` functions are not explicitly used in Node.js, however they are used internally by OpenSSL for some APIs. While we are unable to confirm with certainty at this stage, we believe that Node.js is not invoking the code paths that use these functions. + +Combined with the difficulty of exploiting this defect and the likelihood that Node.js is not using APIs that require the internal use of these functions, this defect is considered to have a very low severity for Node.js users. + +### [CVE-2016-0799](https://www.openssl.org/news/vulnerabilities.html#2016-0799): Fix memory issues in BIO_*printf functions + +**Assessment**: All versions of Node.js **are unaffected** + +This defect can serve as a potential Denial of Service (DoS) vector or be used for causing memory corruption. The `BIO_*printf()` functions are used internally by OpenSSL, however the only path by which an API call by Node.js invokes these functions has a default certificate size limit, which is not changed by Node.js, that removes the possibility of exploiting this defect. Therefore we believe that Node.js is unaffected by this defect. + +### [CVE-2016-0702](https://www.openssl.org/news/vulnerabilities.html#2016-0702): Fix side channel attack on modular exponentiation + +**Assessment**: All versions of Node.js **are affected**, with low severity + +This defect has been labelled the _[CacheBleed Attack](https://ssrg.nicta.com.au/projects/TS/cachebleed/)_. + +This defect enables attackers to execute side-channel attacks leading to the potential recovery of entire RSA private keys. It only affects the Intel [Sandy Bridge](https://en.wikipedia.org/wiki/Sandy_Bridge) (and possibly older) microarchitecture when using hyper-threading. Newer microarchitectures, including Haswell, are unaffected. Disabling hyper-threading is an option for mitigating against this attack.