北京
一個只有11字節的惡意數據包，就能讓一臺運行OpenSSL的服務器內存沸騰、進程被殺——這不是黑客電影里的夸張橋段，而是安全團隊剛披露的真實漏洞。Okta紅隊給這個手法取了個形象的名字：HollowByte。
漏洞的核心藏在每個TLS握手的起點。每次握手，客戶端都會發出一條ClientHello消息，外層包裹著一個4字節的記錄頭，頭里明明白白寫著“接下來的消息體有多長”。舊版OpenSSL看了這個數字，二話不說就按照攻擊者聲明的尺寸去分配接收緩沖區，哪怕真正的數據連影子都還沒出現。Okta紅隊發現，只要構造一個11字節的載荷，就能讓這條預分配路徑全速跑起來：讀頭→grow_init_buf()→OPENSSL_clear_realloc()→malloc(攻擊者指定的大小)。整個過程沒有任何校驗，一個數據包就能逼著malloc一把申請最高131 KB的內存，然后工作線程就傻等著永遠不會到來的數據，陷入無限阻塞。
傳統的連接耗盡攻擊，比如Slowloris，靠的是大量掛起連接，慢慢耗光服務器線程。而HollowByte的狠辣之處在于，它疊加了一層內存碎片化效應，效果更隱蔽也更致命。當惡意連接被斷開，OpenSSL會釋放掉那塊緩沖區，但glibc并不會把中小尺寸的堆內存立刻還給操作系統，而是留在自己的池子里等待復用。攻擊者只要反復發起連接，每次都報一個隨機大小的長度，就能讓glibc管用的碎片回收徹底失靈。結果就是：哪怕攻擊者已經離線，服務器的駐留內存（RSS）仍在持續爬升，唯有殺死進程才能收場。
Okta紅隊在未打補丁的OpenSSL + NGINX環境里實測了兩種極端場景。在1 GB內存的機器上，凍結的碎片內存累積到547 MB時，系統直接觸發了OOM Killer，服務被當場掐死。而在16 GB內存的機器上，攻擊只啃掉了總內存的25%，還遠沒碰到常規的連接數上限——也就是說，那些依賴最大連接數限制的防御手段，在HollowByte面前幾乎完全失效。
由于OpenSSL幾乎支撐著半個互聯網，受影響的軟件清單長得令人焦慮：Web服務器Apache和NGINX赫然在列，Node.js、Python、Ruby、PHP這些主流語言運行時一個都沒跑掉，就連MySQL和PostgreSQL這樣的數據庫也躺了槍。
OpenSSL的修復思路很干脆：不再輕信記錄頭里自報的尺寸。通過pull request #30792、#30793和#30794，開發團隊把緩沖區的增長方式改成了增量模式——只有真真切切從網線上收到多少字節，就擴多少空間。如此一來，如果一個攻擊者宣稱要傳海量數據卻只發來11個字節，服務器幾乎是零成本應對。這個改動被悄然并入OpenSSL 4.0.1，并向后移植到了3.6.3、3.5.7、3.4.6和3.0.21。值得注意的是，OpenSSL沒有將其作為一個安全漏洞緊急發布，而是將其視為一項強化改進。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
