来源: https://thehackernews.com/2026/07/openssl-hollowbyte-flaw-could-freeze.html
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 日。这些分支上所有早于修复版本的发布都已包含此修复。常规的补丁流程不会指向这些修复：没有可供扫描器匹配的标识符，也没有可供参考的公告。
内存无法恢复
就其本身而言，这是一种连接耗尽攻击，而这种攻击方式与Slowloris攻击一样古老。HollowByte 之所以能够持续攻击，关键在于 glibc 库。当攻击者断开连接时，OpenSSL 会释放缓冲区，但 glibc 会保留一些小块和中等大小的数据块以供重用，而不是将它们返回给内核。
该攻击会在每个连接上改变声称的内存大小，在 Okta 的测试中，这足以阻止内存分配器重用已释放的内存。堆内存碎片化，驻留内存集大小不断增加，即使攻击者离开后，驻留内存集的大小仍然保持增加状态。
在 Okta 的 NGINX 测试中，一台 1GB 的服务器因内存不足 (OOM) 而被强制关闭，其中 547MB 的内存以碎片形式冻结。在一台 16GB 的服务器上，HollowByte 占用了 25% 的系统内存，但连接数始终没有超过上限，这就是为什么红队表示“标准的连接数限制防御措施无法阻止它”。
这些数据均来自 Okta 官方，该公司并未同时发布任何漏洞利用代码。截至 7 月 18 日，Hacker News 在 GitHub 上未发现任何公开的概念验证代码库。
OpenSSL 认定这不是漏洞
补丁作者 Matt Caswell 在提交的pull request中明确指出：安全团队选择“仅将其视为‘漏洞修复或安全加固’”。OpenSSL 自身的安全策略定义了四个严重级别，从“严重”到“低”，而“漏洞修复或安全加固”并不在其中。
即使是低级别的漏洞也会获得一个 CVE 编号、一条更新日志说明以及漏洞页面上的一个条目。而 HollowByte 漏洞却三者皆无。Hacker News 在OpenSSL 4.0.1的发布说明以及全部 23 条更新日志条目中均未发现任何关于此修复的提及。
OpenSSL并未解释原因。他们的理由是：每个连接131KB的内存占用量很小，每个TLS服务器都会为每个连接分配内存，而有限的内存分配并非漏洞。Okta的解释是，这些内存永远不会被释放。
Hacker News 已向 OpenSSL 询问 HollowByte 问题为何优先级低于 Low，以及该修复是否已包含在扩展支持的 1.1.1 和 1.0.2 分支中。此外，他们还向 Okta 询问除 glibc 之外的其他内存分配器是否也存在碎片问题。如有任何回复，本文将持续更新。
该项目的界限比表面看起来要模糊得多。今年1月，OpenSSL将CVE-2025-66199（低危）分配给TLS 1.3证书压缩漏洞，该漏洞会导致对等方提供的证书长度在验证之前占用大量堆缓冲区，每个连接大约占用22 MiB。
那个方案需要四个条件同时满足：证书压缩功能已编译到程序中、压缩算法可用、扩展名已协商，以及服务器端请求客户端证书。HollowByte 则不需要这些条件。
6月9日发布的同一版本还发现了CVE-2026-34183漏洞，评级为“中等”，该漏洞会导致QUIC PATH_CHALLENGE处理程序内存无限增长。这两个漏洞都属于内存耗尽型拒绝服务攻击（DoS），并且都已获得漏洞编号。
该版本还修复了 18 个 CVE，包括 PKCS7_verify() 中的一个高危释放后使用漏洞，因此任何运行这些上游版本的人都会在未被告知的情况下获得修复。
下游情况更糟。红帽官方文档中明确指出，其默认做法是向后移植而不是直接更新版本，因此即使打了补丁，软件包仍然会报告其构建时所用的版本。通常情况下，可以通过安全公告和 OVAL 信息源来解决这个问题，这两者都与 CVE 编号相关联。但这里并没有对应的 CVE 编号。
这就只剩下软件包变更日志或维护者了：询问他们是否基于 6 月 9 日的版本进行重新构建，或者采用了补丁，该补丁是master 和 4.0 的pull request 30792，3.6、3.5和 3.4 的 pull request 30793，以及3.0的 pull request 30794。
如果您自行构建 OpenSSL，请升级到列出的版本并重启加载旧版本的程序。
该修复仅针对 TLS。Caswell 在 pull request 中写道，之所以没有修改 DTLS，是因为要正确地修改它会带来更大的侵入性，而且项目组决定暂时不处理它。Hacker News 对比了 OpenSSL 3.6.2 和 3.6.3 版本中的源代码，发现修复后的 DTLS 握手文件在字节上完全相同。在最新版本 4.0.1 中，该路径仍然根据对端声明的长度来调整缓冲区大小。
OpenSSL 尚未对该路径进行分类，也未承诺修复。发行说明、变更日志和漏洞页面均未提及此事。但拉取请求中有相关说明。
OpenSSL 的问题分类工具将其判定为部署问题，而非协议缺陷。
更新（2026 年 7 月 20 日）： 负责 HollowByte 分类的 OpenSSL 开发人员 Alexandr Nedvedicky 在 Hacker News 发布后做出了回应。
他将 HollowByte 与今年 6 月获得 CVE 编号的 QUIC 漏洞区分开来。他表示，QUIC 漏洞是一个协议问题，因为代码没有限制其接收的 PATH_CHALLENGE 帧的数量。而 HollowByte 在他看来，问题在于服务器处于阻塞模式且未设置任何限制，这更像是部署选择问题，而非协议缺陷。
他优先处理了关于OpenBSD的报告，OpenBSD不使用glibc，并表示他“没有考虑到glibc可能带来的任何影响”。这种行为正是Okta案件的核心所在。
他也不确定已发布的修复程序是否能彻底解决问题。Caswell 的补丁程序虽然保守地增加了缓冲区大小，但仍然使用了 realloc 函数，而 Nedvedicky 表示他“不确定这是否对 glibc 有任何改进”。Okta 建议无论如何都要升级。
对于该修复程序是否已纳入扩展支持的 1.1.1 和 1.0.2 分支，他拒绝置评，并指出请参阅 OpenSSL 的支持门户。