CVE-2024-45159

**漏洞编号：** CVE-2024-45159

**漏洞归属组件：** third_party_mbedtls

**CVSS V3.1分值：** 9.8

**漏洞简述：** 
TLS 服务器可以使用可选的客户端身份验证，通过 mbedtls_ssl_conf_authmode(..., MBEDTLS_SSL_VERIFY_OPTIONAL) 配置，完成握手后，可以调用 mbedtls_ssl_get_verify_result() 检查客户端是否提供了证书，以及该证书是否有效。如果没有提供证书或者证书无效，该函数的返回值应为非零，并且特定的位会被设置，以指示证书具体问题所在。

特别是，对于 TLS 1.3，如果客户端提供的证书在其 keyUsage 扩展中没有设置 digitalSignature 位，则在 mbedtls_ssl_get_verify_result() 的返回值中，应该设置 MBEDTLS_X509_BADCERT_KEY_USAGE 位。同样地，如果证书的 extKeyUsage 扩展中没有列出 clientAuth，返回值应设置 MBEDTLS_X509_BADCERT_EXT_KEY_USAGE 位。

然而，在 Mbed TLS 3.6.0 中，TLS 1.3 出现了问题：这两个位始终没有设置，无论 keyUsage 和 extKeyUsage 扩展是否正确。特别是，如果证书唯一的问题就是这两个扩展不正确，mbedtls_ssl_get_verify_result() 会错误地返回 0，将证书错误地认为是完全有效的。

此问题仅影响 TLS 1.3 可选客户端身份验证。强制身份验证（MBEDTLS_SSL_VERIFY_REQUIRED）不受影响（如果客户端证书缺失或无效，它会正确地终止握手并发送致命警报）。TLS 1.2 身份验证不受影响。TLS 1.3 服务器身份验证不受影响，因为在 3.6.1 之前，TLS 1.3 服务器身份验证无法设置为可选。

**影响性分析说明：** 
攻击者如果持有一个仅在 TLS 客户端身份验证之外有效的证书，仍然能够将其用于 TLS 客户端身份验证。

需要注意的是，证书本身必须是有效的（特别是需要由服务器信任的 CA 签发），除了 keyUsage 和 extKeyUsage 扩展值之外。

**受影响版本：** 
Mbed TLS 3.2.0 至 3.6.0

该漏洞出现在 3.2.0 版本，这是第一个支持 TLS 1.3 客户端身份验证的版本。

需要注意的是，在 3.6.0 版本之前，TLS 1.3 在默认的编译时配置中是禁用的，因此该漏洞在默认构建中不存在。而在 3.6.0 中，TLS 1.3 默认启用，导致该漏洞在默认配置下存在。

**规避方案或消减措施：** 
解决方案：
建議升级到 Mbed TLS 3.6.1 或以上的版本。

规避方案：
可以通过强制使用 TLS 1.2 来避免该问题，特别是对于使用可选客户端身份验证的连接。也就是说，所有调用 mbedtls_ssl_conf_authmode(..., MBEDTLS_SSL_VERIFY_OPTIONAL); 的服务器，应该同时调用 mbedtls_ssl_conf_max_tls_version(..., MBEDTLS_SSL_VERSION_TLS1_2); 来确保使用 TLS 1.2。

**参考链接：** 
https://github.com/Mbed-TLS/mbedtls/releases/
https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.1
https://github.com/advisories/GHSA-cr54-4mf7-rg5v
https://mbed-tls.readthedocs.io/en/latest/security-advisories/mbedtls-security-advisory-2024-08-3/
https://mbed-tls.readthedocs.io/en/latest/security-advisories/

OpenHarmony / third_party_mbedtls
关闭

内容风险标识

评论 (1)

OpenHarmony / third_party_mbedtls关闭 .gitee-modal { width: 500px !important; }

内容风险标识

CVE-2024-45159

评论 (1)

搜索帮助

OpenHarmony / third_party_mbedtls
关闭