OpenSSL 1.0.2m on 2nd November 2017 #271
Comments
|
We have an LTS release day for 6.x schedule for the 7th. We could bundle
this in and do a 8.9.1
Thoughts?
…On Oct 30, 2017 6:38 PM, "Rod Vagg" ***@***.***> wrote:
Doing this here instead of in @nodejs/security
<https://github.com/orgs/nodejs/teams/security> since there's nothing
sensitive here as far as I can tell. /cc @nodejs/security-wg
<https://github.com/orgs/nodejs/teams/security-wg>
Forthcoming OpenSSL releases
============================
The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.1.0g and 1.0.2m.
These releases will be made available on 2nd November 2017 between
approximately 1300-1700 UTC.
This is a bug-fix release. It will also include a fix for the low
severity security issue previously published here:https://www.openssl.org/news/secadv/20170828.txt
Please also note that, as per our previous announcements, support for
1.0.1 ended on 31st December 2016.
Yours
The OpenSSL Project Team
The issue in question is:
Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735)
===================================================================
Severity: Low
If an X.509 certificate has a malformed IPAddressFamily extension,
OpenSSL could do a one-byte buffer overread. The most likely result
would be an erroneous display of the certificate in text format.
As this is a low severity fix, no release is being made. The fix can be
found in the source repository (1.0.2, 1.1.0, and master branches); seehttps://github.com/openssl/openssl/pull/4276. This bug has been present
since 2006.
So, that's pretty low, I think the only reason this is even listed as a
security problem is because it's a buffer over-read and it they're leaving
open the possibility that it could be more than just an "erroneous display".
So IMO we shouldn't rush this out but we need to keep up to date with
OpenSSL as much as possible to retain trust. So I guess just line this up
with the closest releases.
In proposed LTS release schedule, this is going to miss v8.9.0 by 2 days
and will then have to wait for a bit over a month for v8.9.1. I assume that
Boron has a similar schedule to Carbon in this schedule. Are we OK with
letting this dangle for a month? We'd just have to communicate it somewhere
publicly.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
<#271>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAecV0EyDl3tgWeIiYb4EnyqCtghQFR3ks5sxlAAgaJpZM4QL9JI>
.
|
|
Oh lovely, this just appended to the announcement: No further details. So yeah, let's plan for shipping this ASAP afterward. If it were just this very-low issue then bundling with a standard release would be fine, but with this new "moderate" one and not having any details about it, we should do the usual planning for releasing within a day or two afterward. We normally tell people via nodejs-sec & the blog that we'll do an assessment after release and decide how to proceed after that. Perhaps the assessment will tell us that it's not even applicable to Node, in which case we can just bundle the upgrade with the next release. |
|
Proposed announcement nodejs/nodejs.org#1430, who's around to review? @MylesBorins? |
|
Done
I'm going to be on an airplane for much of the 2nd so may not be able to
help get it out on that day. Should be able to help put out 4 / 6 on Friday
if I have good internet access in Colombia
…On Oct 30, 2017 7:53 PM, "Rod Vagg" ***@***.***> wrote:
Proposed announcement nodejs/nodejs.org#1430
<nodejs/nodejs.org#1430>, who's around to review?
@MylesBorins <https://github.com/mylesborins>?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#271 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAecV-x9IcjRhjh37CKyyQLpYDYdG5Bzks5sxmF9gaJpZM4QL9JI>
.
|
|
I'd be very confident that we won't need to act urgently on this so Friday will be the likely earliest that we need to act. My rough guess is that we may be able to defer this even until the next scheduled releases but we'll have to wait and see what the moderate is! |
|
Announcement has gone public. We're going to need some folks in @nodejs/crypto to help with assessment when the medium is public on Thursday. A look at CVE-2017-3735 would be helpful too and that could be done now since it's public @ openssl/openssl#4276 |
CVE-2017-3735 fixed buffer overread in parsing X.509 certificate which supports extensions defined in RFC3779. Node disables RFC3779 support by defining A moderated severity includes TLS client crash and it has a possibility to affect Node. I will make a security assessment as soon as it is released to see if an urgent release is needed. |
|
@rvagg as a suggestion it would have been good to have a reference to this in the security repo. I was looking for it earlier when I saw the post to nodejs-sec and was looking in the security repo as I thought that was were it would be if we had an open issue. |
|
do we have an update on this? |
|
Can someone give a summary of CVE-2017-3736 as it impacts Node? @shigeki? We need to decide whether rushing releases is worth it. I haven't had a look in detail yet but I'm hearing that exploits are pretty improbable. |
|
found discussion in nodejs/security, will sync with discussion here when we come up with a proposal, thanks @MylesBorins for pointing me to that! |
|
Proposed announcement @ nodejs/nodejs.org#1443, pls review! Summary release plan:
|
Doing this here instead of in @nodejs/security since there's nothing sensitive here as far as I can tell. /cc @nodejs/security-wg
The issue in question is:
So, that's pretty low, I think the only reason this is even listed as a security problem is because it's a buffer over-read and it they're leaving open the possibility that it could be more than just an "erroneous display".
So IMO we shouldn't rush this out but we need to keep up to date with OpenSSL as much as possible to retain trust. So I guess just line this up with the closest releases.
In proposed LTS release schedule, this is going to miss v8.9.0 by 2 days and will then have to wait for a bit over a month for v8.9.1. I assume that Boron has a similar schedule to Carbon in this schedule. Are we OK with letting this dangle for a month? We'd just have to communicate it somewhere publicly.
The text was updated successfully, but these errors were encountered: