OpenSSL 最近修復了一個被稱為 HollowByte 的記憶體漏洞。這個問題非常有趣且危險，因為它不需要複雜的攻擊載荷，甚至不需要經過身份驗證，只要發送極短的 TLS 請求，就能讓伺服器的記憶體被慢慢吃光，最終導致服務崩潰。
這類攻擊屬於拒絕服務攻擊（Denial-of-Service, DoS），其核心原理與早期的 Slowloris 攻擊類似，都是透過維持大量不完整的連線來耗盡伺服器資源。但 HollowByte 的特殊之處在於它利用了記憶體分配器的運作機制，讓記憶體在連線中斷後依然無法回收。
漏洞觸發的技術細節
在 TLS 握手過程中，每個訊息都有一個 4 位元組的標頭（Header），其中 3 個位元組用來宣告接下來訊息主體（Body）的長度。
在受影響的 OpenSSL 版本中，伺服器在收到這個標頭後，會立即根據宣告的長度去申請對應的記憶體緩衝區（Buffer），而不會先驗證這個長度是否合理，也不會等到主體內容真正傳來才分配空間。對於 ClientHello 訊息，這個上限最高可達 131 KB。
攻擊者可以發送一個僅 11 位元組的請求（包含標頭），宣告一個較大的長度，然後就保持沈默，不發送任何主體內容。此時，伺服器端的工作執行緒（Worker Thread）會進入阻塞狀態，等待永遠不會到來的資料。
為什麼記憶體無法回收
一般來說，當攻擊者斷開連線時，OpenSSL 會釋放（Free）該緩衝區，記憶體應該回歸系統。然而，在 Linux 系統常用的 glibc（GNU C Library，負責記憶體分配的標準函式庫）中，為了效能考量，小於或中型大小的記憶體區塊在釋放後，並不會立刻還給作業系統核心（Kernel），而是會被 glibc 保留在自己的快取池中以便下次重複使用。
HollowByte 的巧妙之處在於，攻擊者在每次建立連線時，會隨機變動宣告的長度。這導致 glibc 分配的記憶體區塊大小不一，產生了嚴重的記憶體碎片化（Memory Fragmentation）。由於碎片化太嚴重，glibc 無法有效地重複利用這些空間，導致伺服器的駐留記憶體（Resident Set Size）持續攀升。
實務影響與風險
根據 Okta 紅隊的測試，這種攻擊能繞過傳統的連線數量限制。因為即便連線數沒達到上限，記憶體也可能先被碎片化耗盡。在 1 GB 記憶體的伺服器上，僅 547 MB 的記憶體被碎片化鎖死，就足以觸發 OOM-killer（Out of Memory killer，Linux 核心在記憶體不足時強制殺死進程的機制）將 NGINX 伺服器關閉。
更嚴重的問題在於 OpenSSL 官方對此漏洞的處理方式。OpenSSL 團隊將此問題定義為 Bug 或安全性強化（Hardening），而非正式的安全性漏洞。這意味著該修復沒有被賦予 CVE 編號，也沒有在正式的安全性公告或變更日誌（Changelog）中標註。
對於維運工程師來說，這造成了巨大的偵測困難。如果你依賴自動化掃描器（Scanner）來檢查 CVE 編號，或者閱讀安全性公告來決定是否更新，你將完全不知道自己的系統存在這個風險。
修復建議與限制
受影響的版本包含 OpenSSL 4.0.1 之前的版本，以及 3.6.3、3.5.7、3.4.6、3.0.21 之前的所有分支。建議立即更新至上述版本並重啟相關服務。
需要注意的是，目前的修復僅針對 TLS 協議。由於 DTLS（基於 UDP 的 TLS）修復成本較高且涉及較深層的改動，OpenSSL 官方目前尚未對 DTLS 部分進行修復，這意味著使用 DTLS 的服務依然處於風險之中。
對於使用 Red Hat 等採取 Backport（將新版修復移植回舊版本）策略的發行版，由於沒有 CVE 編號可對照，建議直接確認 OpenSSL 的更新紀錄是否包含相關的 Pull Request（例如 master 分支的 PR 30792）。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。