GnuTLS CURLINFO_TLS_SESSION / CURLINFO_TLS_SSL_PTR 类型混淆

漏洞概述

curl_easy_getinfo 函数在处理 CURLINFO_TLS_SESSION 和 CURLINFO_TLS_SSL_PTR 时，对于 GnuTLS 后端错误地返回了 CURLSSLBACKEND_OPENSSL 值，导致 struct curl_tlssessioninfo 的 backend 字段类型混淆。

漏洞代码位置

漏洞位于源代码文件：
https://github.com/curl/curl/blob/2db8ae480fdcae7f005bf847fbbf837821c8184c/lib/vquic/vquic-tls.c#L211

1
2
3
4
5


#elif defined(USE_GNUTLS)
  (void)give_ssl_ctx; /* gnutls always returns its session */
  info->backend = CURLSSLBACKEND_OPENSSL;
  info->internals = ctx->gtls.session;
  return TRUE;

漏洞影响

当调用方根据 backend 字段的值进行动态决策时，会将 gnutls_session_t 类型错误解析为 SSL_CTX 或 SSL 类型，导致类型混淆。

具体影响取决于应用程序代码和调用的 OpenSSL 函数，至少可能导致崩溃，但不能排除其他潜在影响，特别是考虑到 libcurl 广泛的平台和版本支持。

受影响版本

8.15.0

复现步骤

构建同时链接 GnuTLS 和 OpenSSL 的应用程序
应用程序使用 curl_easy_getinfo 调用 CURLINFO_TLS_SESSION 或 CURLINFO_TLS_SSL_PTR
当 info->backend == CURLSSLBACKEND_OPENSSL 时，代码调用 OpenSSL 函数

缓解因素

要利用此漏洞，应用程序必须同时链接 GnuTLS 和 OpenSSL，这种情况相当罕见。因此，此漏洞的影响有限。

修复情况

该漏洞已通过 https://github.com/curl/curl/pull/17976 修复。

讨论总结

开发团队认为此问题更可能是一个常规错误而非安全漏洞，主要原因包括：

HTTP/3 不支持多SSL后端
应用程序在使用 GnuTLS 时不会调用 OpenSSL 函数
实际安全影响极不可能发生

最终报告状态被标记为"不适用"（Not Applicable），但按照项目透明度政策，报告已被公开披露。