OpenSSL upgrades: January 28th 2016

[rvagg]

@nodejs/security

Ref: https://mta.openssl.org/pipermail/openssl-announce/2016-January/000058.html

Forthcoming OpenSSL releases

The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2f, 1.0.1r.
These releases will be made available on 28th January between approx. 1pm and 5pm (UTC). They will fix two security defects, one of "high" severity affecting 1.0.2 releases, and one "low" severity affecting all releases.
Please see the following page for further details of severity levels: https://www.openssl.org/policies/secpolicy.html
Please also note that, as per our previous announcements, support for 1.0.0 and 0.9.8 releases ended on 31st December 2015 and are no longer receiving security updates. Support for 1.0.1 will end on 31st December 2016.

High severity is defined as:

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 round of updates were also high.

Note that this impacts all our active release lines, v0.10 and v0.12 use 1.0.1 and v4 and v5 use 1.0.2. It's very possible that both of the bugs being fixed don't impact Node.js at all or that our impact assessment is much lower than theirs due to how we are using the particular parts of OpenSSL affected. Therefore, we will have to make an assessment on the urgency of release when we see the details on the 28th. It may be prudent to plan for releases for some or all of our release lines within one or two days of the 28th regardless, in order to give some predictability to users. The only catch here is that we only have two commits queued up for v0.10, a doc fix and a fix to tools/install.py to generate proper header files (a welcome fix). So it's harder to justify a v0.10 release if the OpenSSL fixes turn out to be irrelevant for Node.js. v0.12 has more meaty commits (7), worthy of a stand-alone release.

I'll prepare an announcement for nodejs-sec and nodejs.org and post a draft here but I'd like to hear thoughts on my above point about planning for releases regardless of impact.

[shigeki]

I will be available at that day and make assessment and upgrade if high severity affects Node.
As the openssl-1.0.1 in v0.10 and v0.12 has only one low security, I think it is a good chance to call for someone volunteer in collaborators who wants to work on upgrading of v0.10 and v0.12 and I can take care of it as a reviewer.
If we do it, the release of v0.10 and v0.12 might be a day or so behind from 4.2 and 5.5. How about is this?

[Fishrock123]

Should I delay this week's stable release until thursday for this?

[rvagg]

@Fishrock123 / @nodejs/release yes I think best to put off stable until we have this figured out.

We discussed this briefly in the LTS call today, given that the 28th is a Thursday and we're unlikely to have it ready to roll the same day we'd be either releasing on Friday or Saturday which is very far from ideal! I'll try and come up with a proposal for a strategy on this today so we can move forward.

[shigeki]

Forthcoming openssl-1.0.2f and 1.0.1r raised the minimum DH size of a tls client connection from 768 to 1024 bits. ( openssl/openssl@a4530ce and openssl/openssl@f5fc940 )
Node-5.x has already had the limits with an option but Node-4.x and Node-v0.12 are affected. It should be noted in the release notes.

[rvagg]

The @nodejs/security team will also be releasing some low-severity fixes related to HTTP processing. Patches are currently under review in our private repository with full disclosure coming at time of release.

Given our experience with taking OpenSSL updates and immediately applying them to all release lines on top of our own security patches, and then shipping them all in a roughly synchronised manner, and also taking into account that the two defects in OpenSSL are labelled "high" rather than "critical", I'm proposing that we defer release until Monday, the 1st of February. This way we avoid a scramble that increases the likelihood of a botched release and we don't give users a Friday or weekend release that they need to apply to their production environments.

However, we ought to also allow for the possibility that the impact of the OpenSSL defects are closer to "critical" for Node.js users the gap between disclosure and release of 4 days is unacceptable, requiring us to act sooner, possibly on the Friday or even Saturday. We should look to @nodejs/crypto to help us make that call.

In accordance with this, below is my proposed post to nodejs-sec and nodejs.org (I won't post an additional issue on GitHub, we'll use this thread). The CVSS score is incorrect, I'll update it when @jasnell, who is handling our fixes, has a chance to come up with it.

Further, I propose that we also turn off anonymous access to Jenkins on Friday, restricting it to collaborators and @nodejs/build until release, so that we have the chance to properly put our patches through the system.

Please review and comment @nodejs/security, I'll post this within 24 hours unless there are objections.

---

OpenSSL upgrade low-severity Node.js security fixes

Summary

The Node.js project will be releasing new versions across all of its active release lines early next week (possibly sooner, pending full impact assessment) to incorporate upstream patches from OpenSSL and some additional low-severity fixes relating to HTTP handling. Please read on for full details.

OpenSSL

The OpenSSL project announced this week that they will be releasing versions 1.0.2f and 1.0.1r on the 28th of January, UTC. The releases will fix two security 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 are normally statically compiled. Therefore, all active release lines are impacted by this update.

At this stage, due to embargo, the exact nature of these defects is uncertain as well as the impact they will have on Node.js users.

Low-severity Node.js security fixes

In addition, we have some fixes to release relating to Node.js HTTP processing. We categorise these as low-severity and are not aware of any existing exploits leveraging the defects. Full details are embargoed until new releases are available.

Common Vulnerability Scoring System (CVSS) v3 Base Score:

Metric	Score
Base Score:	4.8 (Medium)
Base Vector:	CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Attack Vector:	Network (AV:N)
Attack Complexity:	High (AC:H)
Privileges Required:	None (PR:N)
User Interaction:	None (UI:N)
Scope of Impact:	Unchanged (S:U)
Confidentiality Impact:	Low (C:L)
Integrity Impact:	Low (I:L)
Availability Impact:	None (A:N)

Refer to the CVSS v3 Specification for details on the meanings and application of the vector components.

Impact

Both the OpenSSL updates and the Node.js fixes affect all actively maintained release lines of Node.js.

• Versions 0.10.x of Node.js are affected.
• Versions 0.12.x of Node.js are affected.
• Versions 4.x, including LTS Argon, of Node.js are affected.
• Versions 5.x of Node.js are affected.

Release timing

As the OpenSSL release is planned for late in the week, we are currently planning on deferring Node.js releases until early next week due to the complexity of the upgrade process and a preference for not releasing security fixes at the end of the work-week or on the weekend.

Releases will be available at, or shortly after, Monday the 1st of February, 11pm UTC (Monday the 1st of February, 3pm Pacific Time) along with disclosure of the details defects to allow for complete impact assessment by users.

However, when details of the OpenSSL defects are released on the 28th, our crypto team will be making a more detailed assessment on the likely severity for Node.js users. In the event that the team determines that the fixes are critical in nature for Node.js users we may choose to expedite releases for Friday or Saturday in order to ensure that users have the ability to protect their deployments against a disclosed vulnerability.

Please monitor the nodejs-sec Google Group for updates, including a decision within 24 hours after the OpenSSL release regarding release timing, and full details of the defects upon eventual release: https://groups.google.com/forum/#!topic/nodejs-sec

Contact and future updates

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

Please contact security@nodejs.org 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.

[mhdawson]

The proposed post looks good to me

[shigeki]

I'm fine with this.

[indutny]

LGTM

[MylesBorins]

This is a bit of a tangent, but what is our current policy with announcing this to the community via social media?

Do we generally hold off until the release is out or do we start getting the word out once this copy is on the blog?

[rvagg]

No policy on social media, mostly that's out of our control, even the @nodejs twitter account is beyond our reach for this. For individual collaborators, just be responsible, and if you don't know what that is then ask. In this case, I've been sharing as much of this here as I can because the OpenSSL announcement is public. There is additional information we are keeping private and connected to this but what you see here is already in the open so it can be treated as such IMO.

Posting to nodejs-sec and nodejs.org now.