Java 15以上版本爆加密漏洞：CVE-2022-21449

如果您的服务器在2022 年 4 月重要补丁更新 (CPU)之前运行任何 Java 15、16、17 或 18 版本，且使用ECDSA 签名加密：SSL 证书和握手（允许拦截和修改通信）、签名的 JWT 、SAML 断言或OIDC id 令牌，甚至是WebAuthn身份验证消息，那么，攻击者可以轻松伪造攻陷。
现实世界中几乎所有的 WebAuthn/FIDO 设备（包括 Yubikeys *）都使用 ECDSA 签名，许多 OIDC 提供商使用 ECDSA 签名的 JWT。

如果您在生产环境中部署了 Java 15、Java 16、Java 17 或 Java 18，那么您应该停止正在执行的操作并立即更新以安装2022 年 4 月重要补丁更新中的修复程序。

更新：Oracle 的官方公告还列出了 Java 旧版本也可能受到影响，包括 7、8 和 11。
在同一个 CPU 中还报告了其他安全漏洞，因此（一如既往）即使您运行的是较旧的 Java 版本，也值得升级。另一方面，OpenJDK公告仅列出了受此特定问题 (CVE-2022-21449) 影响的版本 15、17 和 18。、

Oracle 对此的 CVSS 评分为 7.5，对机密性或可用性没有影响， ForgeRock 将其评为完美 10.0 。

背景：ECDSA 签名
ECDSA 代表Elliptic Curve Digital Signature Algorithm，它是一种广泛使用的标准，用于签署各种数字文档。与旧的 RSA 标准相比，椭圆曲线密钥和签名往往要小得多，以实现同等安全性，因此它们被广泛用于大小非常宝贵的情况。例如，用于两因素身份验证的 WebAuthn 标准允许设备制造商从广泛的签名算法中进行选择，但实际上，迄今为止制造的几乎所有设备都仅支持 ECDSA 签名（一个值得注意的例外是使用 RSA 的 Windows Hello签名；大概是为了与旧的TPM硬件兼容）。

为什么现在才发现？
您可能想知道为什么在 Java 长期以来一直支持 ECDSA 的情况下这才被曝光。它一直很脆弱吗？
不，这是一个相对较新的错误，是通过将 EC 代码从本机 C++ 代码重写为 Java 引入的，这发生在 Java 15 版本中。
尽管这种重写在内存安全性和可维护性方面有好处，但似乎经验丰富的密码工程师并未参与实施。
最初的 C++ 实现不容易受到这些错误的影响，但重写却是。两种实现似乎都没有很好的测试覆盖率，即使是对 ECDSA 规范的最粗略阅读也肯定会建议测试无效的 r 和 s 值被拒绝。

时间线

• 2021 年 11 月 11 日– 发现问题并向 OpenJDK 漏洞报告电子邮件地址披露。
• 2021年11月 11 日– 确定了在 Java 15 中引入错误的JDK 更改。
• 2021 年 11 月 12 日——甲骨文的初步确认。
• 2021 年 11 月 18 日– Oracle 确认了该错误并表示将在未来的重要补丁更新 (CPU) 中对其进行修补。它被分配了跟踪 ID S1559193。
• 2021 年 11 月 18 日– ForgeRock发布安全公告，通知我们的客户不要将受影响的 Java 版本部署到生产环境中。
• 2022 年 1 月 14 日– 向 Oracle 询问状态更新。告知该修复程序针对 2022 年 4 月的 CPU，计划于 4 月 19 日发布。
• 2022 年 3 月 25 日– 再次与 Oracle 确认修复将在 4 月 CPU 中进行。通知他们，如果到那时该错误仍未修复，ForgeRock 将继续进行全面披露。
• 2022 年 4 月 19 日– 甲骨文在 4 月 CPU 中发布了修复程序。
• 2022 年 4 月 19 日——文章发表。