This template is ONLY for reporting security bugs. If you are reporting a
Download Protection Bypass bug, please use the "Security - Download
Protection" template. For all other reports, please use a different
template.

Please READ THIS FAQ before filing a bug: https://chromium.googlesource.com
/chromium/src/+/master/docs/security/faq.md

Please see the following link for instructions on filing security bugs:
https://www.chromium.org/Home/chromium-security/reporting-security-bugs

NOTE: Security bugs are normally made public once a fix has been widely
deployed.

VULNERABILITY DETAILS
Please provide a brief explanation of the security issue.

OpenSSL released an advisory here with a bug in their RSA code, CVE-2017-3738:
https://www.openssl.org/news/secadv/20171207.txt

This affects our code on all processors which support AVX2.

Of the affected algorithms (RSA, FFDH, DSA), only RSA is used by Chrome. Specifically, RSA-2048 keys are affected. It's true that, as upstream wrote in their advisory, the obvious attacks are mitigated by the RSA anti-glitching countermeasures, but we are less sanguine than OpenSSL about the possibility of obtaining a Bleichenbacher-like oracle using this bug.

Chrome, being a client, does not handle private keys very much, so this is pretty minor for Chrome:

WebCrypto allows web applications to generate and use origin-specific RSA private keys. Depending on how the application uses the RSA key, it could be affected. (Signing is unlikely to be able to expose the oracle, if one exists, but decryption would if repeated attacker-controlled inputs are allowed.)

WebRTC can be configured to generate RSA-2048 keys (the bug does not affect RSA keys of other sizes), but they default to ECDSA now and previously defaulted to RSA-1024, which is unaffected. A web application that explicitly generated RSA-2048 keys and reused them would be affected by any oracles exposed by this bug because WebRTC in Chrome has not turned off static RSA yet (it really really should...).
https://developers.google.com/web/updates/2016/06/webrtc-ecdsa

Client certificates are not affected as those call out to the OS crypto implementations.

Thus we don't think it warrants an M63 post-stable merge. We would like to request an M64 merge however, as that has only just branched. I've added the Merge-Request-64 tag here.

The fix rolled into Chromium in https://chromium-review.googlesource.com/c/chromium/src/+/814237, which just landed. I will defer merging until next Monday, so the change will have had some time to bake on canary first.

VERSION
Chrome Version: all recent
Operating System: all