OpenSSL HollowByte漏洞可用11字节TLS请求冻结服务器内存

导语：Okta红队披露了OpenSSL中的一个拒绝服务漏洞HollowByte，仅需11字节TLS请求即可冻结服务器内存。该修复已在6月发布但未分配CVE、未发布安全公告，也未在更新日志中标注。

11字节即可让未打补丁的OpenSSL服务器为一条永远不会到达的消息预留多达131 KB内存。在Okta测试的glibc系统上，这些内存在进程重启前都不会被释放。

OpenSSL于6月通过修复发布了HollowByte，但未分配CVE、未发布安全公告，也未在更新日志中标注该修复。报告并命名该拒绝服务漏洞的Okta红队于周四公布了细节。

修复版本包括OpenSSL 4.0.1、3.6.3、3.5.7、3.4.6和3.0.21，均发布于6月9日。这些分支上每个早于修复版本的版本都存在该漏洞。常规补丁流程无法将你指向它们：没有供扫描器匹配的标识符，也没有可供阅读的安全公告。

该漏洞的根源在于OpenSSL轻信了攻击者提供的数据。每个TLS握手消息都带有一个4字节的头部，其中三个字节声明正文的长度。较旧版本在头部到达的瞬间就根据所声明的大小扩展接收缓冲区，此时正文尚未到达一个字节，握手自身的检查也尚未运行。对于入站ClientHello，上限为131 KB。然后工作线程被阻塞，等待永远不会到达的正文。不需要认证、会话或密钥交换。

单看这是一个连接耗尽攻击，与Slowloris一样古老。HollowByte之所以棘手在于glibc。当攻击者断开连接时，OpenSSL释放缓冲区，但glibc将中小型块保留供复用，而不是归还给内核。该攻击在每个连接上都变换所声明的大小，在Okta的测试中，这足以使分配器无法复用它释放的内容。堆碎片化，常驻集大小攀升，并且在攻击者离开后很长时间内保持高位。

在Okta对NGINX的测试中，一台1 GB的服务器因547 MB内存被碎片冻结而被OOM杀死。在16 GB服务器上，HollowByte锁定了25%的系统内存，却从未越过连接上限，这也是红队表示"标准的连接限制防御无法阻止它"的原因。这些数据来自Okta自身，且未随数据发布漏洞利用代码。The Hacker News截至7月18日未在GitHub上发现公开的概念验证代码库。

编写该补丁的Matt Caswell的Pull Request直言不讳：安全团队选择将其作为"错误或加固"修复处理。OpenSSL自身的安全策略定义了四个严重等级——从严重到低，但"错误或加固"不在其中。即使是低危问题也会获得CVE、更新日志说明和漏洞页面条目。HollowByte这三项都没有。The Hacker News在发布说明或OpenSSL 4.0.1更新日志的全部23个条目中均未发现该修复的提及。

OpenSSL未说明原因。以下是他们的论据：每个连接131 KB很小，每个TLS服务器都会为每个连接分配内存，有界的分配并非漏洞。Okta的回应是：该内存永远不会被回收。The Hacker News已询问OpenSSL为何将HollowByte的分级低于低危，以及该修复是否覆盖了扩展支持分支1.1.1和1.0.2。同时询问Okta该碎片化问题是否在glibc以外的分配器上仍能复现。

该项目的标准比看起来更微妙。今年1月，OpenSSL将CVE-2025-66199（评级为低危）分配给TLS 1.3证书压缩漏洞，其中对等方提供的长度在验证前扩大了堆缓冲区，每个连接约22 MiB。该漏洞需要四个条件同时满足：编译时启用证书压缩、有可用的压缩算法、协商该扩展，以及在服务器上请求客户端证书。HollowByte则不需要这些条件中的任何一个。

同一6月9日的发布还为QUIC PATH_CHALLENGE处理器中的无界内存增长分配了CVE-2026-34183，评级为中危。两者都是内存耗尽型DoS，且都获得了编号。该发布还关闭了18个CVE，包括PKCS7_verify()中的一个高严重性释放后使用漏洞，因此任何运行这些上游版本的人都已在未被告知的情况下获得修复。

下游情况更为糟糕。红帽的记录在案的默认做法是回移植而非迁移版本，因此打了补丁的软件包仍然报告其构建时的版本。正常情况下能解决此问题的是基于CVE名称的安全公告和OVAL订阅源。此处没有CVE可作为键值。

来源信息

来源：The Hacker News

原文链接：https://thehackernews.com/2026/07/openssl-hollowbyte-flaw-could-freeze.html

作者：info@thehackernews.com (The Hacker News)