わずか11バイトでOpenSSLのメモリを凍らせる「HollowByte」——静かな修正が残す可用性リスクとサプライチェーンの盲点

今日の深掘りポイント

• 11バイトという極小のTLS入力で、未修正のOpenSSLが接続ごとに最大約131KBを確保し、プロセス再起動まで解放されない設計パスが突かれる点が本質です。攻撃者にとっては約1.2万倍の「資源増幅」が成立するため、低レートでも累積的に効いてくるのが厄介です。
• glibc環境では断片化が加速しやすく、メモリの「確保は進むがOSに返らない」状況が長引くため、CPUや帯域を飽和させない静かな可用性劣化として現れるのが読みどころです。
• 修正は6月に入った一方で、CVEや公式アドバイザリが未公開という「静かな修正」になっており、SBOM連動のパッチ適用ワークフローやベンダー経由の情報伝達で見落としが起きやすい構造的リスクが露呈しています。
• WAFはTLS終端より上位で効くことが多く、初期TLS処理の手前で発火する本件は、CDN/ロードバランサ/終端方式の選択が被弾確率を大きく左右します。観測と緩和はL4/L5層での手当てが重要です。
• 現場対応は「すぐに更新」「同時ハンドシェイクの制御」「プロセスの自動再起動ガード」「TLSハンドシェイク失敗メトリクスの監視」の四点セットが実効的です。パッチ適用の遅れを前提にした運用ガードで被害の尾を短くするのが肝要です。

はじめに

OpenSSLの新手の可用性脅威「HollowByte」は、驚くほど小さなTLS入力でサーバー側に相対的に大きなメモリ確保を誘発し、しかもそのメモリがプロセス再起動まで解放されにくい挙動を突くものです。発見はOktaのRed Teamで、OpenSSLは6月に修正を取り込んだものの、現時点でCVEや公式アドバイザリが示されていないという異例の情報流通になっています。大きなトラフィックも高いCPU負荷も見えないのに、徐々に常駐メモリが増え、ある閾値で突然ワークロードが転ける——そんな「静かな可用性崩壊」を体現する事例です。基盤ソフトの透明性と、エッジ構成の選択が可用性を左右する時代相に、示唆が多いインシデントです。

参考として、報道では1GBメモリのサーバーで約547MBが「凍結」し、16GB環境で25%がロックされた例が示されています。glibcシステムでは断片化の副作用で被害が増幅する懸念も指摘されています。修正は進んだ一方でCVE未付与という背景事情が、パッチ適用判断の遅延を招きやすい点も見逃せません。

深掘り詳細

事実関係の整理

• 未修正のOpenSSLに対し、11バイトのTLSリクエストで接続ごとに最大約131KBを確保し、確保済みメモリがプロセス再起動まで解放されない問題があると報じられています。発見はOkta Red Teamで、OpenSSLは6月に修正を取り込んだものの、CVEや公式アドバイザリは公表されていません。
• Oktaのテストとして、1GBサーバーで約547MBが固定化、16GBサーバーで25%がロックされる観測が伝えられています。とくにglibc採用システムではメモリ断片化が進みやすく、実メモリ返還が進まないことで可用性に影響が及ぶとされています。
• HollowByteは接続枯渇系の古典的手法の延長線にありつつ、必要パケットが極端に小さいため、帯域やCPUの増強では防ぎにくい「省コストDoS」の性質を持ちます。
• 一部報道ではDTLSへの懸念にも言及がありますが、公式アドバイザリが非公開のため影響範囲の一次情報は未確認です。運用判断は保守的に取り、影響可能性を前提に構成・監視で備えるのが賢明です。
• 以上は公開報道に基づくもので、テクニカルな再現手順や具体的なパッチ差分は現時点で一般公開されていない前提です。

出典: The Hacker Newsの報道

編集部のインサイト

• 攻撃経済性の高さが最大の懸念です。11バイト入力で最大131KBの確保を誘発するなら、単純比で約1.2万倍の資源増幅が成立します。帯域課金や検知回避の観点でも、攻撃者に著しく有利な性質です。少数のボットでも「静かな累積」が可能で、レート制限の設計次第では時間的にじわじわと効き続けます。
• 従来のL7 DoSはアプリケーション層で観測しやすいのに対し、これはTLSハンドシェイク前後の挙動で発火するため、アプリケーションやWAFのログに痕跡が乏しい可能性が高いです。逆にL4/L5の観測（同時ハンドシェイク数、TLSネゴ失敗率、非常に短寿命なTLS接続の急増など）が早期兆候をとらえる主戦場になります。
• glibcにおける断片化の悪化は、アロケータの実装差に依存する副作用です。脆弱なパスがプロセスライフサイクルでメモリを解放しないなら、断片化に拍車がかかり、実質的に「メモリ洩れに似た」ふるまいとして観測されます。アロケータの変更は根本対策にはなりませんが、断片化の悪化を抑える緩和策として検討の余地があります。
• サプライチェーンの観点では、CVEや公式アドバイザリがない「静かな修正」は、SBOM連動更新や脆弱性管理のトリガーに乗らず、適用遅延の温床になります。ベンダーアプライアンスやOSS依存プロダクトにおいて、「いつの間にか直っていたが、気づかず未更新」のリスクを招きやすいです。CVE前提の運用設計に過度に依存しないための運用線形化が必要です。
• これが可用性の話に留まらない理由は、RDoS（身代金DoS）との親和性にあります。小さな帯域で確実にメモリを食い潰せるなら、脅迫コストが下がり、攻撃の下限規模が引き下がります。警戒レベルは一段階引き上げるべきです。

脅威シナリオと影響

• シナリオ1: 低レート・分散型の「静かな累積」攻撃です。多数のIPから閾値以下の頻度でTLSを叩き、常駐メモリを少しずつ積み上げていき、ピーク時間帯に余力を奪い切るパターンです。MITRE ATT&CKではActive Scanning（T1595）で露出サービスを特定し、Endpoint Denial of Service（T1499、特にサービス／アプリケーション枯渇系）として実行する流れが想定されます。
• シナリオ2: RDoS型の脅迫です。事前に少量のトラフィックで影響度をデモし、支払い拒否時に分散強度を上げて継続的にメモリを固定化する攻撃です。防御側の再起動やスケールアウトのコストが嵩む時間帯を狙うと効果が増します。マッピング上はT1595に続くT1499の連携で説明できます。
• シナリオ3: マルチベクタDoSへの合成です。L4の同時接続制御をかいくぐるために、アプリ層の軽量な攻撃と組み合わせ、閾値判定を攪乱しつつ、TLS初期処理でメモリを固定化する複合戦術です。検知と緩和の層を跨いで最適化されるため、単一層のレート制限では抜けやすいです。

業種横断の影響

• 金融・政府・産業の基盤系で使われるリバースプロキシ、APIゲートウェイ、MTA、VPNなど、OpenSSLでTLS終端する役物は軒並み影響候補になります。CDNでTLS終端していないオリジン直結構成は特に注意が必要です。
• コンテナ／Kubernetesでは、Pod単位のメモリ上限に早く達し、OOMKillやCrashLoopBackOffに雪崩れ込むリスクが高まります。オートスケールで凌げても、コスト面とスロット逼迫で別の影響が出ます。
• マルチテナント環境では、共有ノードのメモリ圧迫によるノイジーネイバー問題が発生しやすく、隣接サービスのSLO悪化につながります。

注記

• DTLSへの波及が懸念されるとの言及はありますが、一次情報の公開が現時点で確認できないため、影響は仮説段階と扱うのが妥当です。少なくともTLS終端経路については速やかな更新と監視強化を優先すべきです。

セキュリティ担当者のアクション

今すぐやること

• 影響資産の棚卸しを行い、OpenSSLをTLS終端に使う全てのプレーンとミドルウェア（Webサーバ、メールサーバ、VPN、プロキシ、API GW、ロードバランサ）を可視化することが最優先です。SBOM、資産管理DB、Ingress設定、コンテナイメージ、アプライアンスのリリースノートを突き合わせることが有効です。
• ベンダー／ディストリ更新を最優先で適用することです。CVEや公式アドバイザリが未公開でも、6月の修正を含む最新安定版に追随する方針に切り替えることが望ましいです。アプライアンスはファーム更新の入手性を確認し、適用ウィンドウを前倒しすることです。
• 同時TLSハンドシェイクの上限、ハンドシェイクタイムアウト、1-IPあたりだけでなくグローバル同時ハンドシェイクの制御を導入し、低レート分散攻撃への耐性を上げることです。L4ロードバランサやプロキシのキュー構造に合わせ、バックプレッシャを早く発動させることが重要です。
• 監視をL4/L5に寄せることです。TLSネゴ失敗率、非常に短寿命のTLS接続比率、プロセスの常駐メモリ（RSS）上昇速度、スレッド数、ハンドシェイクキュー長をダッシュボード化し、しきい値超過時に通知することです。アプリ層ログに痕跡が出ないことを前提に、下層の指標で兆候をつかむことです。
• メモリ増加に対する自動回復を仕込むことです。systemdのMemoryMaxやWatchdog、Kubernetesのliveness/readiness probeとHPA、メモリしきい値超過時の優雅な再起動を標準化し、「放置で悪化」を防ぐことです。再起動がセッション影響を生む場合はドレインとコネクションマイグレーションを合わせて設計することです。

次にやること

• エッジでの終端方式を再評価することです。CDNや専用ロードバランサでTLSを終端し、オリジンのOpenSSL露出を減らす構成に寄せることが、当面の実効策になります。異なるTLSスタックを使う終端との多様化も、単一実装バグの系統リスクを下げます。
• ミドルウェア側で、非常に小さな初期TLSレコードを連発するクライアントに対する動的な遮断・遅延（tarpitting）的制御を検討することです。適用は段階的に行い、誤検知による正当トラフィック影響を評価することが重要です。
• 断片化の副作用を抑えるため、アロケータやスレッドアリーナ設定の見直し、ワーカプロセスの定期サイクル再起動（graceful）を導入することです。根本対策にはパッチが不可欠ですが、断片化の悪化を抑える運用は効果があります。

継続してやること

• 脆弱性管理のトリガーをCVE一辺倒から、コミットメッセージ、メンテナリリース、重要コンポーネントの「セキュリティ修正らしき変更」自体に反応する運用へ広げることです。SBOMとCIを連携し、「静かな修正」でも検出・検討できるようにすることが肝要です。
• DoS系演習に「低帯域・高効率のTLS初期処理狙い」を組み込み、監視・検知・自動回復の運用が意図通りに機能するかを定期的に確かめることです。
• サードパーティや子会社・委託先の終端方式・更新方針も点検し、サプライチェーン横断での可用性SLO維持計画を整備することです。

復旧とインシデント対応の観点

• 兆候検知時は、影響ノードの優先度付き切り離しと、終端の一時的なオフロード（CDN／別リージョン）を素早く適用することです。
• 再起動で解放される性質を踏まえ、ローリングでの優雅な再起動を標準手順化し、SLA影響を最小化することです。
• 攻撃検知後は、閾値前提の静的レート制限から、観測ベースの適応制御へ移行し、短寿命TLSセッションの異常比率を抑え込むことが重要です。

参考情報

• The Hacker News: OpenSSL ‘HollowByte’ Flaw Could Freeze Server Memory with Just 11-Byte Request
  https://thehackernews.com/2026/07/openssl-hollowbyte-flaw-could-freeze.html

本件は、帯域やCPUの派手な消耗戦ではなく、運用の盲点をついて「静かに、しかし着実に」可用性を奪うタイプの攻撃です。パッチ適用を最優先にしつつ、観測の重心をL4/L5に寄せ、プロセスのライフサイクルを運用で守ることで、被害の尾を短くできるはずです。サプライチェーンの透明性と運用の機動性が試される案件として、今後の教訓化まで意識して取り組むべきだと考えます。