GnuTLS与OpenSSL类型混淆漏洞分析

本文详细分析了curl库中CURLINFO_TLS_SESSION和CURLINFO_TLS_SSL_PTR接口在GnuTLS后端错误返回OpenSSL标识导致的类型混淆问题,包含漏洞代码定位、影响评估及修复方案。

curl库GnuTLS后端类型混淆漏洞技术分析

漏洞概述

curl库的curl_easy_getinfo函数在处理CURLINFO_TLS_SESSIONCURLINFO_TLS_SSL_PTR参数时,对于GnuTLS后端错误地返回CURLSSLBACKEND_OPENSSL标识,导致类型混淆问题。

技术细节

漏洞代码定位

lib/vquic/vquic-tls.c第211行发现缺陷代码:

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;

结构体定义

1
2
3
4
struct curl_tlssessioninfo {
  curl_sslbackend backend;
  void *internals;
};

影响分析

  1. 类型混淆风险:调用方根据backend字段进行动态决策时,会将gnutls_session_t类型错误解析为SSL_CTX/SSL类型
  2. 潜在影响
    • 应用程序崩溃(最可能)
    • 未知影响(取决于具体应用代码和调用的OpenSSL函数)
  3. 触发条件
    • 应用程序必须同时链接GnuTLS和OpenSSL
    • 使用curl_easy_getinfo查询TLS会话信息
    • 代码基于backend字段值调用OpenSSL函数

修复方案

通过GitHub Pull Request #17976完成修复,正确设置GnuTLS后端标识符。

受影响版本

curl 8.15.0

补充说明

HTTP/3不支持多SSL后端,实际应用中同时使用GnuTLS和OpenSSL的场景极为罕见,降低了该漏洞的实际安全影响。最终被评估为常规代码缺陷而非安全漏洞。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计