Node: OpenSSL upgrades: May 3rd

[rvagg]

As per https://mta.openssl.org/pipermail/openssl-announce/2016-April/000069.html we are in for another batch of Node.js updates around the 3rd.

The OpenSSL project team would like to announce the forthcoming release of
OpenSSL versions 1.0.2h, 1.0.1t.
These releases will be made available on 3rd May 2016 between approximately
1200-1500 UTC. They will fix several security defects with maximum severity
"high".

As per the security policy:

HIGH Severity. This includes issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to keep the time these issues are private to a minimum; our aim would be no longer than a month where this is something under our control

The last couple of OpenSSL upgrades have been the same severity level and we have had mixed impact from them across our release lines. Node.js v0.10, v0.12, v4, v5 and v6 will all be impacted by this (yes we'll still be updating v5) but the impact could range between _none_ and _high_ for us and we won't know until the release.

As has been our established practice, we will be putting out new releases regardless of impact but we will also be putting out an impact assessment for our release lines prior to cutting the releases. We will not be committing to a time-frame for release but _estimate_ between 24 and 48 hours after we get our hands on the OpenSSL releases. With an impact assessment somewhere within the 24 hour mark.

I'll prepare an announcement for nodejs-sec and nodejs.org asap and it'll be roughly a copy of what we've used in the past for these.

Also, I spoke to one of the OpenSSL maintainers at Collab Summit a couple of months ago and specifically queried their release process, both in terms of frequency and also lead-time. Basically the story is that the lead time isn't going to improve, we'll just have to accept that we react to these, and the frequency is not fixed but we can probably expect roughly the frequency that we've been experiencing this year—a release every one or two months.

Even though I'd love better scheduling and much more lead time from them than we get, my take-away is that the OpenSSL project is in very good hands these days. Code quality is improving, processes are solidifying, investment has increased and there are multiple full-timers on the project now. I have a much higher level of confidence in the project than was warranted a couple of years ago.

/ @nodejs/security

[shigeki]

I can be available at that time.

CVE-2016-2109 was already fixed in https://github.com/openssl/openssl/commit/f32774087f7b3db1f789688368d16d917757421e. It is DoS against ASN.1 BIO api and seems to be low severity.

ALPN behavior was also changed in https://github.com/openssl/openssl/commit/af2db04c9979554ada88d969da6332a827a47599. I will check if it affects Node before release.

[rvagg]

Posted @ http://nodejs.org/en/blog/vulnerability/openssl-may-2016/ & https://groups.google.com/forum/#!topic/nodejs-sec/ZWYOOWaMaV0

[Fishrock123]

Who is doing these? I'm around to do v5 or v6. From the LTS call I think @TheAlphaNerd will take v4, @jasnell maybe taking 0.10 / 0.12?

[evanlucas]

I can help too on v5/v6 if needed

[jasnell]

I can definitely do v0.10 and v0.12 unless someone else wants to take one of them.

[jasnell]

Actually, let me take that back. I've had a couple things pop up today that are going to take quite a bit of my time this week. Would be great if someone else can take v0.10 and v0.12 but if there's no one else who can I'll try to make it work.

[rvagg]

I'd like to do v0.10 and v0.12, I've had enough practice with their quirks so far that I wouldn't mind keeping that focus. @TheAlphaNerd has v4 and offered v5 too but IMO it'd be good to have a singular focus on v4 to keep that solid. @evanlucas and @Fishrock123 how about you toss a coin for v5 and v6? As I said in nodejs/security we've set the precedent that we _don't_ release pure security releases with non-LTS lines so you can include as much other stuff as you're comfortable, that's up to you.

[MylesBorins]

SGTM. I'll get a proposal out in the am

[rvagg]

fwiw we set the expectation that releases would be _on or after_ Thursday, UTC, so there's no great rush and the severity indicators the team has come up with so far don't look particularly dramatic either, so no panic!

[evanlucas]

I'll do v6?

[Fishrock123]

@evanlucas You can take it over if you'd really like. I don't really have an opinion if it should be a minor or not, I hadn't looked at how big the minors were, we could cut them out and do a patch potentially.

v5 will be easy imo. I doubt we'll backport much/anything else.

[evanlucas]

@Fishrock123 ah sorry, totally missed your open pr. I'll take v5 since you already have that proposal out.

[rvagg]

@shigeki @bnoordhuis @indutny here's my workup of your assessment, I'll post this shortly on nodejs-sec and nodejs.org:

---

_(Update 4-May-2016)_ OpenSSL Impact Assessment

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.2h and 1.0.1t. The results of this analysis are included below.

We will be producing new versions this week for all of our active release lines containing the new versions of OpenSSL in order to provide security assurance. We will provide an update here once all releases are available. We anticipate that they will be available on, or soon after, Thursday the 5th of May, UTC.

CVE-2016-2107: Padding oracle in AES-NI CBC MAC check

A man-in-the-middle (MITM) attacker may be able to execute a padding oracle attack to decrypt traffic when a connection uses an AES-CBC cipher and the server runs on an Intel CPU supporting AES-NI. This is a common configuration for TLS servers.

The OpenSSL project has labelled this vulnerability _high severity_.

Assessment: All versions of Node.js are affected by this vulnerability.

CVE-2016-2105: EVP_EncodeUpdate overflow

An overflow can occur in the OpenSSL EVP_EncodeUpdate() function which is used for Base64 encoding of binary data. An attacker must be able to supply large amounts of input data in order to cause an overflow.

Node.js uses the EVP_EncodeUpdate() internally during calls to crypto.Certificate#exportPublicKey() for SPKAC Certificate Signing Requests. User-supplied data must be passed to this method for applications to be vulnerable. This method has been available since Node.js v0.12.

The OpenSSL project has labelled this vulnerability _low severity_.

• Node.js v0.10 is unaffected
• Node.js v0.12, v4, v5 and v6 are affected

CVE-2016-2108: Memory corruption in the ASN.1 encoder

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability.

CVE-2016-2106: EVP_EncryptUpdate overflow

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability

CVE-2016-2109: ASN.1 BIO excessive memory allocation (CVE-2016-2109)

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability

CVE-2016-2176: EBCDIC overread

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability

[bnoordhuis]

@rvagg LGTM. Good write-up.

[mhdawson]

LGTM

[rvagg]

thanks! posted to both places.

[shigeki]

LTGM

[rvagg]

Thanks to everyone involved in patching and fixing this release, very smooth and relatively pain free. I've received feedback on our security processes incl. announcements, analyses and lead-time planning and I believe we're in a really good place with users' level of trust in the predictability, stability and integrity of how we conduct ourselves around these important releases.