OpenSSL Releases 14th August 2018

[rvagg]

@nodejs/release

https://mta.openssl.org/pipermail/openssl-announce/2018-August/000129.html

Forthcoming OpenSSL releases
============================

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.1.0i and 1.0.2p.

These releases will be made available on 14th August 2018 between
approximately 1200-1600 UTC.

These are bug-fix releases. They also contain the fixes for two LOW
severity security issues (CVE-2018-0732 and CVE-2018-0737) which were
previously announced here:

https://www.openssl.org/news/secadv/20180612.txt
https://www.openssl.org/news/secadv/20180416.txt

Yours

The OpenSSL Project Team

So we have CVE-2018-0732 in already in 10.x/master, we floated it @ 772d390.
We also floated 831821b, the ECDSA blinding attack that didn't get a CVE AFAIK. It's also not listed in this advisory, perhaps they're considering it below their threshold even for "Low".

I wasn't aware of CVE-2018-0737, that's:

Cache timing vulnerability in RSA Key Generation (CVE-2018-0737)
================================================================

Severity: Low

The OpenSSL RSA Key generation algorithm has been shown to be vulnerable to a
cache timing side channel attack. An attacker with sufficient access to mount
cache timing attacks during the RSA key generation process could recover the
private key.

I think 2018 is going to be defined by various creative and difficult side-channel attacks. We're going to want to get this one out but I wouldn't call it "critical", just something we might expect pressure on if we don't get it out within a few days. We should probably released patched versions of LTS and then bundle this into the next regular 10.x release.

[MylesBorins]

@rvagg can this go out in a regular LTS release? We have a backlog of 6.x changes.

[rvagg]

@MylesBorins it looks like we didn't float the other patches on anything but master/v10.x so it probably should be a discrete security release, but there's no reason we couldn't bump them up against eachother. Security release followed quickly by a proper 6.x and 8.x (that's pending isn't it?).

I could take LTS releases for this if we can get someone else to do the 1.0.2 patching. Then I'd say proceed with 6.x and 8.x as planned/normal. I've been hearing we have stuff queued but not pushed out, are we following a schedule anymore or are we too stretched on people-time? Do I need to step up and do a standard LTS release or two?

[MylesBorins]

We have an 8.x proposal put together rn, targeting a Sept 4 release 6.x has a handful of patches on staging, but as we are in maintenance we haven't planned anything releases

…

On Wed, Aug 8, 2018, 9:08 PM Rod Vagg ***@***.***> wrote: @MylesBorins <https://github.com/MylesBorins> it looks like we didn't float the other patches on anything but master/v10.x so it probably should be a discrete security release, but there's no reason we couldn't bump them up against eachother. Security release followed quickly by a proper 6.x and 8.x (that's pending isn't it?). I could take LTS releases for this if we can get someone else to do the 1.0.2 patching. Then I'd say proceed with 6.x and 8.x as planned/normal. I've been hearing we have stuff queued but not pushed out, are we following a schedule anymore or are we too stretched on people-time? Do I need to step up and do a standard LTS release or two? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22187 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV_l3F14qYqzRAsjEZK-NUrTqI7WRks5uO4uTgaJpZM4VzSiF> .

[rvagg]

@MylesBorins would you like me to take one of these? Maybe I could queue up a 6.x maintenance with what's on staging in the next couple of weeks, or even Sept 4.

[Trott]

@nodejs/security-wg

[rvagg]

@nodejs/crypto I need some help confirming impact, or lack thereof for CVE-2018-0737 on Node. It's a cache-timing attack that only impacts RSA keygen, nothing else. The fix simply switches to constant-time operations in rsa_builtin_keygen(). But, I believe that we don't expose RSA keygen anywhere or use it for anything internally. So Node wouldn't be impacted by CVE-2018-0737.

[tniessen]

@rvagg See #20090. I am working on implementing key generation following the discussion in #15116, but right now, Node.js should be unaffected by side-channel attacks against RSA key pair generation.

[rvagg]

oh gee ... pointing me to my own issue, my memory really is getting bad. Thanks @tniessen!

[brody4hire]

npm@6.4.0 which resolved its own npm audit warnings was just releases. While they determined it not to pose a real risk I think it would be nice to include if possible.

[Trott]

npm@6.4.0 which resolved its own npm audit warnings was just releases. While they determined it not to pose a real risk I think it would be nice to include if possible.

@brodybits The pull request to add it was opened 40 minutes ago. I think it's going to have to wait for the next release.

[richardlau]

npm@6.4.0 which resolved its own npm audit warnings was just releases. While they determined it not to pose a real risk I think it would be nice to include if possible.

@brodybits The pull request to add it was opened 40 minutes ago. I think it's going to have to wait for the next release.

We also have a policy of waiting two weeks before landing a new version of npm: https://github.com/nodejs/node/blob/master/doc/guides/maintaining-npm.md

Two weeks after the "latest" release has been promoted it can land on master assuming no major regressions are found.