OpenSSL upgrades: March 1st 2016 [1.0.2g, 1.0.1s]

[rvagg]

@nodejs/security

OpenSSL versions 1.0.2g, 1.0.1s.

These releases will be made available on 1st March 2016 between approximately
1300-1700 UTC. They will fix several security defects with maximum severity
"high".

Please see the following page for further details of severity levels:
https://www.openssl.org/policies/secpolicy.html

https://mta.openssl.org/pipermail/openssl-announce/2016-February/000063.html

Same severity level as the January 28th releases, FYI. Impacting 0.10, 0.12, 4 and 5.

[shigeki]

I will be available at that time frame of the release and can make vulnerability assessments.

[bnoordhuis]

I'll be around as well.

[rvagg]

@nodejs/lts we have a quandary to sort out:

• This update impacts on all our release lines
• We can't tell ahead of time whether there is material impact to Node for their vulnerabilities so it's probably best we work on the assumption that we have to release and should probably do it anyway since we have to create a clear message for users
• We have 0.10.43 and 0.12.11 backed up and they contain critical fixes for the http parser regression that I don't think any of us are comfortable delaying much more, 0.12 contains a bunch of other fixes that have been on hold for too long as well. I honestly don't know what to do with both of these releases, input would be helpful!
• 4.4 is scheduled for release next week (afaik) and contains a bunch of extra stuff including the semver-minor's
• If the openssl update contains items that impact Node in any serious way then it's not ideal that we lump together a lot of changes in a single release and leave LTS users without a means to find a middle-ground if there are any regressions for their use-case, i.e. the philosophy we've been taking with releasing security updates mostly isolated from other updates on LTS.

And for @nodejs/ctc, this to consider: this could be the new norm for OpenSSL. I'm going to try and catch up with someone doing a talk on where OpenSSL is heading at collab summit at the end of April to try and understand better what we should expect. But if we're going to see more regular updates with as little lead-time as this and we're left having to assume that Node is impacted, how do we let that interact with our normal release process, particularly for LTS where we are trying to be steady and intentional (witness the long RC process for recent v4's). In a way we've made this difficult for ourselves by being so dogged on statically linking everything together, but that's really not something we can undo without making the install experience very frustrating for non-Linux users, but perhaps we can lean harder in to making it more straightforward for packagers on Linux at least (tbh I don't know what this means and whether there are actual issues to resolve here other than the annoyance that Node requires newer OpenSSL versions than is available on many systems we support).

[rvagg]

@nodejs/security @nodejs/lts here's my proposal:

• Announce ASAP to nodejs-sec and nodejs.org that there is an OpenSSL upgrade landing on the 1st
• Allow ourselves approximately 24 hours to issue an impact assessment prepared by our @nodejs/crypto experts
• Push forward with planned releases next week for all release lines since we have them due anyway, timing to be determined by the OpenSSL release—mostly a question of difficulty of adapting to the release, hopefully it'll be straightforward.
• v0.10 Release proposal: v0.10.43 (Maintenance) #5404 has a fixes for domains and a fix for a regression in http_parser that came via the last security update. It will likely include the new version of OpenSSL unless there are major problems including it at short notice and there are no major impacts for v0.10 from this release. v0.10 users are encouraged to try out the v0.10.43-rc.1 release to ensure that the minor planned fixes do not cause any regressions for them.
• v0.12 Release proposal: v0.10.43 (Maintenance) #5404 has a fixes for domains, a fix for a regression in http_parser that came via the last security update, and some other minor fixes. It will likely include the new version of OpenSSL unless there are major problems including it at short notice and there are no major impacts for v0.12 from this release. v0.12 users are encouraged to try out the v0.12.11.rc.1 release to ensure that the minor planned fixes do not cause any regressions for them.
• v4 the plan for v4 will vary depending on the assessment of the OpenSSL release and we will announce the plan as soon as we have that assessment. If the OpenSSL release contains important fixes that are relevant to Node.js users then we will release a v4.3.2 with just the OpenSSL update included. On the other hand, if the OpenSSL release is deemed to be of low impact to Node.js users and not requiring urgent upgrade then we will proceed with the v4.4.0 release that was planned for this week anyway and it will include the new version of OpenSSL unless there are major problems including it at short notice.
• v5 Release proposal: v5.7.1 #5464 is a regular update to Node.js v5, we are excluding semver-minor changes from this release although it has a fixes for some regressions included in v5.7.0. It will likely include the new version of OpenSSL unless there are major problems including it at short notice and there are no major impacts for v5 from this release. It will proceed as planned for next week unless anything serious comes up.

I'm going to write up a notice to nodejs-sec and nodejs.org that uses the above plan and will post it here for feedback but I'm going to be on a plane for the next 15 hours so would like to have approval or adjustments to the plan and move to a quick notification post based on that and a short review period here.

Can I have some +1's on the plan please? Particularly @thealphanerd and @jasnell on he v4 plan, is this acceptable?

[rvagg]

Plane is delayed, here's my proposed text to post to nodejs-sec and nodejs.org. You have ~15 hours to let me know what you think:

---

March OpenSSL updates

The OpenSSL project announced this week that they will be releasing versions 1.0.2g and 1.0.1s 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.

Node.js v0.10 and v0.12 both use OpenSSL v1.0.1 and Node.js v4 and v5 both use OpenSSL v1.0.2 and releases from nodejs.org and some other distribution sources are statically compiled. Therefore, all active release lines are impacted by this update.

At this stage, due to embargo, it is uncertain the exact nature of these defects, nor what impact they will have on Node.js users, if any.

As we already had minor, non-security releases scheduled for each of our active release lines during this week and next, we will be adjusting our schedule to adapt to the OpenSSL releases depending on their impact on Node.js users.

We will therefore proceed as follows:

Within approximately 24 hours of the OpenSSL releases, our crypto team will make an impact assessment for Node.js users of the OpenSSL releases. This information may vary depending for the different active release lines and will be posted here.

As part of that impact assessment we will announce our release plans for each of the active release lines to take into account any impact. Please be prepared for the possibility of important updates to Node.js v0.10, v0.12, v4 and v5 soon after Tuesday, the 1st of March.

Node.js v0.10 (Maintenance)

A release of Node.js v0.10.43 has been proposed for this week, it currently contains fixes for domains and an important fix for a regression in http_parser that was introduced in v0.10.42. Details of the changes included in this release along with instructions on how to download and use a release candidate (v0.10.43-rc.1) can be found in #5404. Node.js v0.10 users are encouraged to test the release candidate build to ensure compatibility with existing deployments.

If the OpenSSL 1.0.1s release contains important fixes that impact Node.js v0.10 we will endeavour to ensure that our v0.10.43 release contains the update.

Node.js v0.12 (LTS)

A release of Node.js v0.12.11 has been proposed for this week, it currently contains fixes for domains, an important fix for a regression in http_parser that was introduced in v0.12.42, and some other minor fixes. Details of the changes included in this release along with instructions on how to download and use a release candidate (v0.12.11-rc.1) can be found in #5403. Node.js v0.12 users are encouraged to test the release candidate build to ensure compatibility with existing deployments.

If the OpenSSL 1.0.1s release contains important fixes for Node.js v0.12 we will endevour to ensure that our v0.12.11 release contains the update.

Node.js v4 (LTS "Argon")

A significant update to Node.js v4 has been proposed for next week, the 8th of March. You can read about what will be included in Node.js v4.4.0 and find release candidates to test against your deployments at #5301.

If the OpenSSL 1.0.2g update includes important fixes that impact Node.js v4, we may release a v4.3.2 this week with only the security updates in order to provide a low-risk path for Node.js v4 users.

If the OpenSSL 1.0.2g update does not include important fixes that impact Node.js v4, we will continue with our planned v4.4.0 release and also attempt to include the OpenSSL 1.0.2g upgrade. Users of Node.js v4 can then upgrade to v4.4.0 in their own time and allow for proper testing of the changes included.

Node.js v5 (Stable)

A regular update to Node.js v5 has been proposed for this week. You can read about what will be included in the proposed Node.js v5.7.1 at #5464. We are excluding any semver-minor changes from this release although it has fixes for some regressions

If the OpenSSL 1.0.2g release contains important fixes for Node.js v5, we will endevour to ensure that our v5.7.1 release contains the update.

Summary

• Expect an impact assessment of the OpenSSL updates within 24 hours of their release
• Expect releases of Node.js v0.10, v0.12 and v5 this week, possibly containing important security releases
• Expect a Node.js v4.4.0 release next with the possibility of a v4.3.2 security update this week

Please monitor the nodejs-sec Google Group for updates, including an impact assessment and updated details on release timing within approximately 24 hours after the OpenSSL release: https://groups.google.com/forum/#!forum/nodejs-sec

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact [email protected] if you wish to report a vulnerability in Node.js.

Subscribe to the low-volume announcement-only nodejs-sec mailing list at https://groups.google.com/forum/#!forum/nodejs-sec to stay up to date on security vulnerabilities and security-related releases of Node.js and the projects maintained in the nodejs GitHub organisation.

[MylesBorins]

@rvagg LGTM. I was under the impression the v4.4.0 was going to have another week for RC. There are a few more semver minor commits I wanted to try and get in this week, which would give us the next week to hopefully catch any regressions.

AFAIK there is nothing super major omg need to launch yesterday that is in v4.4.0, more semver minor stuff that has been staged for quite some time. I'd much rather be patient and get more stuff in... otherwise it could be 2 - 3 months, or potentially never, for the remaining semver minor commits.

Monday morning I'll put together an assessment / audit of the remaining stuff to be merged. If the openssl vuln is bad for us we should 100% do a v4.3.2 and push out v4.4.0 soon after. I know there is the concern of release fatigue... but if these kind of updates are coming from openssl there is not much we can really do aside from static linking, which as you mentioned can be a non starter.

[rvagg]

@thealphanerd thanks for the update, good to know 4.4.0 is another week out, I'll adjust wording accordingly: we'll proceed with 4.4.0 next week regardless and the openssl update will either be in that release or a special 4.3.2 this week if there is enough of an impact.

[rvagg]

Updated my text above to clarify a few things including the 4.4.0 schedule. Please review.

[bnoordhuis]

Proposed text LGTM.

[rvagg]

One of the problems being addressed is CVE-2016-0799, I don't know why it's public but there's an interesting writeup at https://guidovranken.wordpress.com/2016/02/27/openssl-cve-2016-0799-heap-corruption-via-bio_printf/

It's all about not properly handling allocation failures during large writes using BIO_printf(). We only have one use of BIO_printf() and it's to print a %l so that suggests that we're unlikely to have direct exposure to this one, but it's used so much internally that I don't think it can be ruled out. Would love @nodejs/crypto to have a poke at this one.

[shigeki]

+1 for Rod's proposal.
I guess that the fix for CVE-2016-0799 has already landed because its severity is considered to be low.
Node uses BIO_printf() in tlsSocket.getPeerCertificate() to show an exponent value of RSA public key in a peer certificate.
Reading the comment in openssl/openssl@578b956, the size of a certificate to receive is limited not to be overflowed so that it would not affect Node.
I'm going to look at it later.

[indutny]

Just a heads up, there are other places in node where we use BIO_printf implicitly, through the others OpenSSL methods like X509V3_EXT_print. I will investigate it more carefully today.

[shigeki]

The default size limit of receiving certificate from server is 100k bytes with SSL_MAX_CERT_LIST_DEFAULT in https://github.com/nodejs/node/blob/master/deps/openssl/openssl/ssl/ssl_lib.c#L1920. We don't change its size and this is far less than 32bits.

I confirmed this limit with connecting the server that has a self signed certs of more than 100k bytes.

$ ./node ~/tmp/tls_test/tls_connect.js
connect
{}
error: { Error: write EPROTO 140348587698048:error:1408E098:SSL routines:ssl3_get_message:excessive message size:../deps/openssl/openssl/ssl/s3_both.c:415:

    at exports._errnoException (util.js:859:11)
    at WriteWrap.afterWrite (net.js:767:14) code: 'EPROTO', errno: 'EPROTO', syscall: 'write' }

So I think CVE-2016-0799 does not affect Node.

[indutny]

Alright, I checked it too. Looks safe indeed. Thank you!

[rvagg]

Posted @ https://groups.google.com/d/msg/nodejs-sec/ORAkxchrT4c/COHJb9obGQAJ and http://nodejs.org/en/blog/vulnerability/openssl-march-2016/

[shigeki]

Three more fixes were already landed in 1.0.2, which seem to be low severity.

• CVE-2016-0705: Fix double free in DSA private key parsing openssl/openssl@6c88c71
  A private key is usually provided with a trusted channel. I can't think of a scenario to use this as an attack vector.
• CVE-2016-0797: Fix BN_hex2bn/BN_dec2bn NULL ptr/heap corruption openssl/openssl@c175308
  BN_hex2bn() and BN_dec2bn() are not used in Node.
• CVE-2016-0798: avoid memory leak in SRP openssl/openssl@259b664
  SRP(Secure Remote Password) is not supported in Node.

[rvagg]

Proposed impact assessment to post as a follow-up to our announcement. I'll post this in ~8h so please review so I can get this cleaned up for release.

• @nodejs/release: please note the release timelines I've included below and let me know if you have an alternative suggestion. These releases should all come after this notice goes out please. Friday isn't an ideal release day but we don't exactly have lot of time so if we can do Thursday for any of these then Friday will do. No need to synchronise any of these, there's no embargo to worry about. I'll work up some "Notable items" wording based on the notice below for the OpenSSL upgrades that can be included in all.
  • @Fishrock123 will take 5.7.1, it's mostly ready including release notes (you'll need to take ownership of my release commit on v5.7.1-release tho), there's some more cherry-picking that can be done but IMO we should keep it as semver-patch and keep out the timer changes for just this one. It also needs OpenSSL 1.0.2g of course. I can serve as backup if required on this for any reason.
  • @jasnell || @thealphanerd would one of you mind taking on a 4.3.2 with just OpenSSL 1.0.2g this week? I personally don't see a need to adjust the 4.4.0 schedule. I can serve as backup if required on this for any reason.
  • I'll take on the 0.10.43 and 0.12.11 releases, they are ready sans OpenSSL 1.0.1s, I can push them out as soon as we get that landed.
• @nodejs/lts: I'm including a note in here about the possibility of removing SSLv2 from 0.10 and 0.12, please review that, discussion is going on @ Deprecate SSLv2 support on v0.12 and v0.10 Release#80.
• @nodejs/crypto: please check my wording below. I've filled in all of the meat myself so it's possible I'm not saying things quite right.
• @nodejs/crypto: what's the status of the PRs against the major branches for OpenSSL? I saw there were some errors, do you think it's reasonable to suggest we can get releases out in the next couple of days with this included?
• @nodejs/ctc: please review if you have time

---

OpenSSL March Releases Impact Assessment for Node.js

Our crypto team (Ben Noordhuis, Shigeki Ohtsu and Fedor Indutny) have performed an analysis of the defects addressed in this week's OpenSSL releases, 1.0.2g and 1.0.1s. The results of this analysis are included below.

The overall impact to Node.js users is low, however we will be producing new versions this week for all of our release lines containing the new versions of OpenSSL in order to provide security assurance.

• v0.10.43 (Maintenance) will proceed as planned for this week, it includes fixes for domains and an important fix for a regression in http_parser that was introduced in v0.10.42. It will also now include an upgrade of OpenSSL to 1.0.1s. An important change will be the complete removal of SSLv2 support, see CVE-2016-0800 below.
• v0.12.11 (LTS) will proceed as planned for this week, it includes fixes for domains, an important fix for a regression in http_parser that was introduced in v0.12.10, and some other minor fixes. It will also now include an upgrade of OpenSSL to 1.0.1s. An important change will be the complete removal of SSLv2 support, see CVE-2016-0800 below.
• v4.4.0 (LTS Argon) will proceed as planned for next week and will include an upgrade of OpenSSL to 1.0.2g. We will also produce a v4.3.2 this week with only the OpenSSL upgrade in order to provide a more conservative upgrade path for users wishing to use the new OpenSSL without having to also include all of the additional non-security fixes in v4.4.0.
• v5.7.1 (Stable) will proceed as planned for this week and will include fixes for a number of regressions introduced in v5.7.0 as well as an upgrade of OpenSSL to 1.0.2g.

Release announcements for each of these will be made on the Node.js blog.

CVE-2016-0800: Disable SSLv2 default build, default negotiation and weak ciphers

Assessment:

• Node.js v0.10 an v0.12 are unaffected, unless manually enabling SSLv2 with --enable-ssl2
• Node.js v4 and v5 are unaffected

This vulnerability has been labelled the DROWN Attack and only impacts servers supporting SSLv2:

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: 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: Disable SRP fake user seed to address a server memory leak

Assessment: All versions of Node.js are unaffected

The Secure Remote Password (SRP) feature of OpenSSL is not exposed via Node.js, therefore all versions are unaffected by this defect.

CVE-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: 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: 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.

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 (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.

[MylesBorins]

@rvagg I can easily get a 4.3.2 out the door tomorrow. I had tolled the openssl fix into the latest 4.4.0-rc.3. I'll back it out, cut rc.4 and get the proposal out for 4.3.2 before lunch PST

[rvagg]

Both @shigeki and @bnoordhuis are advocating for removing SSLv2 in nodejs/Release#80. I quite like the option of leaving it in but making it so you have to --security-revert=CVE-2016-0800 --enable-ssl2 to get it working. But that's very likely too much work to get it out this week. However, I can sign up to @shigeki and @bnoordhuis' recommendation on this and push forward to have it removed. Apparently even keeping SSLv2 enabled with the 1.0.1s upgrade requires extra (minor) changes in core and we're losing some default ciphers in the process as well.

If we go with that then the messaging should be changed to say that 0.10.43 and 0.12.11 are coming out with SSLv2 completely removed—I'd have to come up with some justification for this so it doesn't seem like we're just pulling the rug out because we feel like it.

@nodejs/ctc please weigh in on this one.

[shigeki]

Two comments are here.

CVE-2016-0797: Fix BN_hex2bn/BN_dec2bn NULL pointer deref/heap corruption

Assessment: All versions of Node.js are affected, with low severity

This defect can cause memory corruption in certain very rare cases. It is anticipated the security consequences of this problem are minimal.

BN_hex2bn/BN_dec2bn are not explicitly used in Node. They are also implicitly used in some of OpenSSL APIs for X509v3 and asn.1 parser. As far as I checked, it seems that they still are not called from Node APIs but I cannot say that there is no possibilities at all. So I think this is extremely low severity.

CVE-2016-0799: Fix memory issues in BIO_*printf functions

Assessment: All versions of Node.js are affected, with low severity

This defect can serve as a potential Denial of Service (DoS) vector or be used for causing memory corruption. However, the circumstances under which such an attack could be launched are very limited for Node.js.

With #5433 (comment), I can say that Node is not affected by CVE-2016-0799.

Otherwise LGTM.

[nyaaao]

There is a small typo in:

v0.12.11 (LTS) will proceed as planned for this week, it includes fixes for domains, an important fix for a regression in http_parser that was introduced in v0.12.42, and some other minor fixes. It will also now include an upgrade of OpenSSL to 1.0.1s.

v0.12.42 should be v0.12.10

[evanlucas]

If you are using the --enable-ssl2 command-line argument node then HTTPS servers are vulnerable to this attack.

Maybe "If you are using the --enable-ssl2 command-line argument with node, then HTTPS servers are vulnerable to this attack"?

[evanlucas]

If you believe you have a valid use-case for SSLv2 we welcome your input on this.

Should we make this bold so people will actually see it?

[rvagg]

Thanks @nyaaao, fixed (same problem in the original announement, it was fixed on the blog but not the mailing list).

@shigeki thanks for the update, fantastic info, I've included that now, please review my changes.

@evanlucas yes and yes but I'm still looking for feedback on whether we are removing SSLv2 entirely or doing extra work to keep it enabled in this release and moving to something else later or ... I'll make a call on this in a couple of hours but I'd really appreciate more input. Please review nodejs/Release#80.

[shigeki]

@rvagg That's fine. LGTM.

[bnoordhuis]

Note: The core team is considering entirely removing SSLv2 support in near-future versions of both Node.js v0.10 and v0.12, including the --enable-ssl2 argument.

Just to be clear, SSLv2 is disabled on v0.10-staging and v0.12-staging, even with --enable-ssl2. We'd have to add code to explicitly clear the SSL_OP_NO_SSLv2 flag to make it work again.

[indutny]

LGTM

[Fishrock123]

Did the email already go out, or?

[rvagg]

No, it hasn't still trying to find resolution to the outstanding question of SSLv2 then I need to adjust the wording to suit.

It looks like we're going with removing SSLv2 entirely from v0.10 and v0.12. Speak now if you object.

/cc @mhdawson ^

[mhdawson]

I'm ok with removing SSLv2 entirely.

[MylesBorins]

proposal for v4.3.2 --> #5526

[rvagg]

I'm calling it and adding this:

---

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.

---

I also suggest this means that if you supply the argument then it should bork, not fail silently, it's a breaking change but it needs to be explicit.

[rvagg]

OK, this is live now @ http://nodejs.org/en/blog/vulnerability/openssl-march-2016/#_-update-2-mar-2016-_-openssl-impact-assessment, I'll be working on the nodejs-sec post now, it's kind of tedious with Google Groups.

@Fishrock123 and @thealphanerd go ahead with v4 and v5, do what you need. Here's an entry for the Notable items you can use:

* **openssl**: Upgrade from 1.0.2f to 1.0.2g [TODO: LINK TO PR]
  - Fix a double-free defect in parsing malformed DSA keys that may potentially be used for DoS or memory corruption attacks. It is likely to be very difficult to use this defect for a practical attack and is therefore considered low severity for Node.js users. More info is available at [CVE-2016-0705](https://www.openssl.org/news/vulnerabilities.html#2016-0705).
  - Fix a defect that can cause memory corruption in certain very rare cases relating to the internal `BN_hex2bn()` and `BN_dec2bn()` functions. It is believed that Node.js is not invoking the code paths that use these functions so practical attacks via Node.js using this defect are _unlikely_ to be possible. More info is available at [CVE-2016-0797](https://www.openssl.org/news/vulnerabilities.html#2016-0797).
  - Fix a defect that makes the _[CacheBleed Attack](https://ssrg.nicta.com.au/projects/TS/cachebleed/)_ possible. 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 (and possibly older) microarchitecture when using hyper-threading. Newer microarchitectures, including Haswell, are unaffected. More info is available at [CVE-2016-0702](https://www.openssl.org/news/vulnerabilities.html#2016-0702).