今天的文章來自
HTTP/2 Bomb - Calif [1]
這是一篇由資安公司 Calif 提出的研究,跟先前介紹過的 XBOW 一樣都是 LLM Driven 的 Offensic Security 公司,關於他們的介紹可以上官網 calif.io [2] 看。
在昨天有介紹過 HPACK 壓縮協議,也有提到過它們為了防止 DoS 通常設下的記憶體限制,以及簡單帶過關於 Index/傳輸內容層級發生過的 CVE。
今天就來欣賞 Calif 的 Agents 怎麼把這樣微小的記憶體使用發揮成一個全球浩劫的吧!
大部分的 HTTP/2 實作(如 Envoy、Node.js、Go net/http)都會對「單一請求的 Header 總大小」設定上限(常見如 8KB ~ 64KB)。一旦解碼出來的 Header List 超過這個門檻,伺服器就會立刻回傳 431 Request Header Fields Too Large 或重設該 Stream(RST_STREAM)。
然而,HTTP/2 為了避免單一 Frame 超過最大幀限制(預設 16KB),設計了 CONTINUATION Frame (RFC 7540 [3])。規範規定:如果一個 Header Block 太大,一個 HEADERS Frame 裝不下,後面可以緊跟著數個 CONTINUATION Frame,直到最後一個 Frame 帶上 END_HEADERS 標誌為止:
而 (RFC 7540 [3]) 也有明確規定:
在 HEADERS 開始到 END_HEADERS 結束之間,連線上「絕對不能」插入任何其他類型的 Frame,也不允許交錯處理其他 Stream 的資料。
這就硬性使得 Server Side 無法強制斷開連線,並且該 Buffer 段只能一直累積讀取到的資料。
聰明的讀者讀到這邊應該就知道發生什麼了!
所謂的 HTTP/2 Bomb 攻擊就是透過
END_HEADERS 來累積撐爆 Server Side 記憶體用量,導致 DoS。這個漏洞根據 Calif 官方 Post,影響了至少:
啟用了預設 HTTP/2 的 Web Server,幾乎可以說是全世界無一倖免(
其實有點讓我聯想到 XML Parsing 時的 Billion Laughs Attack [4],同樣都是不斷 Callback 前面定義過的大值來放大一個本來不起眼的 Memory 用量達成 DoS。
<?xml version="1.0"?>
<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ELEMENT lolz (#PCDATA)>
<!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>
其實感覺人類在看這類底層協議時,思考方式比較容易被一些既定印象(心理學上說 Schema)給困住?
或者說研究的人其實比較少?
其實我覺得不是每個 LLM Findings 都真的跟 LLM 自身的優勢有關,或許就算在沒有 LLM 的平行時空,這樣的攻擊在 2026 年附近還是會被別的人類研究員提出?!