OpenSSLのTLSハンドシェイクのバッファの過大な割り当て
- カテゴリ
- 脆弱性の公表
Okta Red Teamの2026年7月16日の報告では、OpenSSLには、遠隔の未認証の攻撃者が11バイトのペイロードを送るだけで、ハンドシェイクが始まる前にサーバーに不釣り合いな大きさのメモリを割り当てさせられるサービス拒否の脆弱性HollowByteがある［6］。OpenSSLは修正を含む版を出していたが、CVEを割り当てず、ハードニングの修正に分類した［1］。
脆弱性の内容
OpenSSLの説明では、TLSのハンドシェイクメッセージは4バイトのヘッダで始まる［1］。ヘッダは1バイトの種別と3バイトの長さからなる［1］。旧版のOpenSSLは、ヘッダを読むと、メッセージの本文が届く前に、受信バッファをヘッダが宣言した長さまで広げていた［1］。
Okta Red Teamの報告によると、この段階ではペイロードの検証が無く、malloc()は信頼できないパケットの申告だけに基づいて最大131 KB〔注1〕を割り当てる［6］。ワーカースレッドはその後、届くことのないデータを待ち続けてブロックする［6］。接続が切れるとOpenSSLはバッファを解放するが、glibcは小〜中規模の割り当てをすぐにはOSに返さず、再利用のために保持する［6］。
Okta Red Teamは、宣言するサイズをランダムにした接続を波状に送ると、割り当て器は解放した領域を再利用できず、ヒープが断片化して常駐メモリ（RSS）が上がり続けると説明した［6］。攻撃者が切断した後もサーバーは肥大したままで、メモリを取り戻すにはプロセスを終了するしかないとした［6］。NGINXでの試験では、1 GBのメモリの環境で未修正のサーバーが547 MBの固まって断片化したメモリでOOM-killされた［6］。16 GBの環境では、攻撃は接続数の上限を下回ったまま、システムの全メモリの25%を占有した［6］。
The Hacker Newsは、これらの数値はOkta自身のもので、Oktaは数値と一緒に攻撃コードを公開しておらず、7月18日にはGitHubに公開のPoCのリポジトリを見つけていなかったと報じた［8］。
説明の食い違い
OpenSSLは7月21日の投稿で、報告が述べる挙動は実在し、それに応じてOpenSSLを変更したと説明した［1］。ただし報告は、2つのまったく異なる事柄を1つの見出しにまとめているとした［1］。割り当ては接続ごとで上限があり、約128 KiBのハンドシェイクメッセージの最大長を超えるものは拒否するため、1つの接続が任意の量のメモリを使うことは無かった［1］。
OpenSSLの説明では、報告の停止の原因は割り当ての大きさではない［1］。停止は、TCPのハンドシェイクを終えてTLSのハンドシェイクを始め、送信を止めた接続を、サーバーがタイムアウトの無いブロッキングソケットで待つことで生じ、以前から知られるslowlorisの類型の攻撃に当たる［1］。通常の資源のホストではメモリ不足ではなくワーカーの枯渇を観測し、停滞した接続を解放するとすぐに回復した［1］。報告のメモリ不足の結果はメモリの限られたホストでのもので、増幅はその故障の形を生んだのではないが、早めることはありうる［1］。
接続の終了後のメモリについて、OpenSSLは、解放したメモリをOSに返すかは割り当て器が決めることだとした［1］。glibcとLinuxで接続の終了後も常駐メモリが高いままになる挙動を再現したが、常駐メモリは同時のハンドシェイクのピークで決まる高水位で頭打ちになり、再利用されたと説明した［1］。ランダムなサイズを含む攻撃を繰り返しても際限なく増えず、修正の前と後のビルドで同じだった［1］。
時系列
| 日付 | 主体 | 内容 | 資料 |
|---|---|---|---|
| 2026年 | OpenSSL | 4.0.1、3.6.3、3.5.7、3.4.6、3.0.21を公開し、同じ日のセキュリティ勧告にCVE-2026-34183を載せた | ［4］ |
| 2026年 | Debian | openssl 3.6.3-1をunstableに、4.0.1-1をexperimentalに受理した | ［5］ |
| 2026年 | Okta | Red TeamがHollowByteの報告を公開した | ［6］ |
| 2026年 | OpenSSL | 報告の評価と修正の扱いについて判断の理由を示す投稿を公開した | ［1］ |
| 2026年 | Debian | openssl 3.5.7-1~deb13u2をstable-securityに受理した | ［5］ |
| 2026年 | Debian | openssl 3.0.22-1~deb12u1をoldstable-securityに受理した | ［5］ |
対象の製品と版
OpenSSLは、段階的な割り当ての変更が、6月9日に公開した版に含まれると説明した［1、4］。OpenSSL 1.1.1と1.0.2は公開のサポートを終え、延長サポートの契約の下でだけ保守されており、契約の顧客はサポート対象のリリースでこの変更を受け取る［1］。Okta Red Teamは、影響を受けるソフトウェアにWebサーバー（Apache、NGINX）、言語ランタイム（Node.js、Python、Ruby、PHP）、データベース（MySQL、PostgreSQL）が含まれるとした［6］。
修正と回避策
OpenSSLは、ハンドシェイクのバッファを宣言された長さに頼らず、データの到着に応じて最大1 TLSレコード（16 KB）ずつ広げる方式に変えたと説明した［1］。大きなメッセージを宣言して送らない相手が生む割り当ては、1レコード分までになった［1］。
OpenSSLのnginxでの試験では、全接続が約65 KBのメッセージを宣言する条件で、1ワーカーの最悪のピーク常駐メモリが約102 MBから53 MBに下がった［1］。現実的なサイズの混在では、約70 MBから55 MBに下がった［1］。残りのうち接続あたり30 KB程度は宣言された長さに関係のない通常の接続ごとの状態で、攻撃者が制御できるものではない［1］。
OpenSSLの説明では、DTLSには段階的な割り当てを適用しておらず、メッセージの最大長がDTLSの割り当ても抑える［1］。これは未了の作業として扱い、再検討する［1］。The Hacker Newsによると、修正を書いた開発者はプルリクエストで、DTLSは正しく直すとはるかに大きな変更になるため手を付けず、当面は扱わないことにしたと書いた［8］。同紙が3.6.2と3.6.3のタグのソースを比べたところ、DTLSのハンドシェイクのファイルは修正の前後でバイト単位で同一だった［8］。
OpenSSLは運用者への推奨を2つ挙げ、後者のほうが重要だとした［1］。
- 段階的な割り当ての変更を含むリリースに更新する［1］
- それとは別に、ハンドシェイクとアイドルのタイムアウトを設定し、同時接続の数に上限を設け、送信元ごとのレート制限をかけ、ノンブロッキングI/Oを使う［1］
Okta Red Teamは、ディストリビューションのOpenSSLのパッケージを直ちに更新するよう勧めた［6］。
ハードニングの修正とした判断
OpenSSLの投稿によると、同じリリースではQUICのPATH_CHALLENGEの大量送信の問題にCVE-2026-34183（Moderate）を割り当て、HollowByteにはCVEを割り当てなかった［1］。判断の決め手は影響に上限があるかどうかで、HollowByteの割り当ては接続ごとに上限があり、残るリスクは通常の導入時の制御で扱える遅い接続の問題だとして、ハードニングの修正に分類した［1］。分類は判断であり、新しい情報で分析が変われば見直すとした［1］。3.5.7のリリースノートは、この版をセキュリティ修正のリリースとし、修正したCVEの最も高い深刻度をHighとしている［2］。
OpenSSLは、修正をGitHubの通常のプルリクエストで公開のまま開発したと説明し、勧告とCVEを出さなかったのは意図した分類で、隠蔽ではないとした［1］。一方、勧告や変更履歴を追う人には優先する合図が無かった点を認め、CHANGES.mdに変更と収録したリリースを記す項目を後から加えた［1］。3.5系と3.6系のリリースノートには、該当する版の節に、ハンドシェイクメッセージのバッファの過大な割り当てを直したとする「aka HollowByte」の行がある〔注2〕［2、3］。
| プルリクエスト | 内容 | 資料 |
|---|---|---|
| #30792 | masterと4.0向けの修正 | ［8］ |
| #30793 | 3.6、3.5、3.4向けの修正 | ［8］ |
| #30794 | 3.0向けの修正 | ［8］ |
| #32039、#32040、#32041、#32042、#32043 | CHANGES.mdに後から加えた項目 | ［1］ |
研究者がoss-securityメーリングリストに出した7月18日の投稿は、修正のプルリクエストの文を引いた［7］。その文には、Okta Red Teamがopenssl-securityチームに報告したセキュリティの問題を受けた変更で、チームは「bug or hardening」だけの修正として扱うことにしたと書かれている［7］。The Hacker Newsによると、OpenSSLのセキュリティ方針は深刻度をCriticalからLowまでの4段階で定めており、「bug or hardening」はその中に無い［8］。OpenSSLは2026年1月、TLS 1.3の証明書圧縮で相手の申告した長さによって検証の前にヒープバッファが広がる不具合に、CVE-2025-66199（Low）を割り当てていた［8］。
The Hacker Newsの7月20日の追記によると、HollowByteをトリアージしたOpenSSLの開発者は、QUICの問題はプロトコルの問題だが、HollowByteは制限を設けずブロッキングモードにしたサーバーの問題で、導入の選択に近いと述べた［8］。この開発者はglibcを使わないOpenBSDでトリアージした［8］。glibcから来るかもしれない影響は考えていなかったと述べ、reallocを使う修正についてはglibcで何かが改善するかは分からないとした［8］。延長サポートの1.1.1と1.0.2に修正が届いたかについてはコメントを控え、OpenSSLのサポート窓口を案内した［8］。
未公表の事項
- Okta Red TeamからOpenSSLへ報告した日
- CHANGES.mdとリリースノートにHollowByteの行を加えた日
- DTLSに段階的な割り当てを適用する時期
- 延長サポートの1.1.1と1.0.2で変更を含む版の版番号
- HollowByteを使った攻撃の観測
注
出典
当事者
- ［1］OpenSSL Project『On the "HollowByte" denial-of-service report』（2026年7月21日公開）
- ［2］OpenSSL Project『OpenSSL 3.5 Series Release Notes』（2026年6月9日公開）
- ［3］OpenSSL Project『OpenSSL 3.6 Series Release Notes』（2026年6月9日公開）
- ［4］OpenSSL Project『Release and Advisory Timeline』（2026年6月9日公開）
関係組織
- ［5］Debian Project『News for package openssl』（2026年6月13日公開）
調査・観測
- ［6］Okta, Inc.『OpenSSL HollowByte: A DoS Hiding in 11 Bytes』（2026年7月16日公開）
- ［7］Openwall『OpenSSL "HollowByte" DoS via attacker-controlled memory allocation size in glibc』（2026年7月18日公開）
報道機関
- ［8］The Hacker News『OpenSSL HollowByte Flaw Could Freeze Server Memory with 11-Byte TLS Requests』（2026年7月17日公開）
更新記録
- 2026年8月6日：公開した。
- 2026年8月25日：Debian Projectのパッケージの受理の記録（出典5）から、openssl 3.5.7-1~deb13u2のstable-securityへの受理を「時系列」に加えた。
- 2026年9月25日：Debian Projectのパッケージの受理の記録（出典5）から、openssl 3.0.22-1~deb12u1のoldstable-securityへの受理を「時系列」に加えた。