2014年4月7日T1
Heartbleed ── TLS の単一バグがインターネットの大半を脆弱化した日
2014年4月7日、 OpenSSL の Heartbeat 拡張に発見されたバッファオーバーリード脆弱性 **CVE-2014-0160(通称 Heartbleed)** が公表された。 Codenomicon と Google Security の Neel Mehta によりほぼ同時期に独立して発見。 攻撃者は対象サーバから最大64KBのメモリを繰り返し読み取り可能で、 結果として秘密鍵、 セッションクッキー、 ユーザのパスワードなどが漏れた。 脆弱なコードは2012年3月の OpenSSL 1.0.1リリースから2年間野放しで、 Apache + nginx が全Webサーバの66%以上を占める当時、 インターネットの大半が影響範囲。 OSS の重要コンポーネントを少人数が無償保守する構造的脆弱性を露呈し、 Linux Foundation の **Core Infrastructure Initiative**(後の OpenSSF) 設立、 OpenBSD による **LibreSSL** フォーク、 Google の **BoringSSL** 派生を生んだ。
メタデータ
- 日付
- 2014年4月7日
- 年代
- 2010s
- Tier
- T1
- 参照年表
- サイバーセキュリティの歴史
- 出典数
- 05
- 関連項目
- 00
Heartbleed ── TLS の単一バグがインターネットの大半を脆弱化した日
2014年4月7日、 OpenSSL プロジェクトは緊急セキュリティ勧告を発表した。 報告者は フィンランドのセキュリティベンダー Codenomicon(現 Synopsys Software Integrity Group の一部) と、 独立に同じバグを発見していた Google Security の Neel Mehta。 割り当てられた識別子は CVE-2014-0160。 Codenomicon はそのバグに「Heartbleed(出血するハート)」という名前と、 滴る血を模した赤いハートのロゴを与えた ── 史上、 ブランディングを伴って公開された最初の大規模脆弱性の一つである。
バグの正体
問題は OpenSSL の Heartbeat 拡張(RFC 6520) の実装にあった。 Heartbeat は TLS 接続の生存確認用の小さな拡張で、 クライアントは「N バイトのデータと、 そのバイト長 N」を送信し、 サーバは同じ N バイトを反射して返す。
OpenSSL の実装(ssl/d1_both.c 内 dtls1_process_heartbeat、 ssl/t1_lib.c 内 tls1_process_heartbeat)は、 クライアントが宣言した長さ N をそのまま信用し、 実際のペイロードと突き合わせる確認を行わなかった。 結果、 攻撃者は「1バイト送るが長さは65,535バイトと宣言する」という細工により、 サーバプロセスのメモリから自分の送ったペイロードの直後にある最大 約64KB を、 毎回少しずつ異なる位置から、 何度でも読み出せた。
C コード上の修正は1行未満 ── 受信した実ペイロード長を確認する条件を追加するだけ。 だがその「1行未満」が、 2012年3月14日リリースの OpenSSL 1.0.1 以降、 約2年間取り残されていた。
何が漏れたか
理論上、 Heartbleed で読める内容は「TLS を終端しているプロセスのメモリ空間に乗っている、 ほぼすべて」だった。 公開検証では次のものが実際に抽出された。
- サーバの秘密鍵(X.509 秘密鍵): これが漏れれば、 過去の通信記録を持つ攻撃者が事後復号できる(Perfect Forward Secrecy を未設定の場合)。 加えて中間者攻撃で本物のサーバを偽装可能。
- アクティブセッションのクッキー / セッショントークン: 認証済みアカウントへの侵入が成立する。
- ユーザがログインフォームに入力した平文パスワード: メモリに一時保持されているタイミングで抽出される事例が複数報告された。
- データベースクエリ結果: アプリ層が処理中の SQL 結果やオブジェクトデータ。
CloudFlare Challenge では、 専門家チームが Heartbleed のみを使い数時間で秘密鍵抽出に成功した。 「秘密鍵までは抜けない」という当初の楽観論は、 数日で覆された。
影響範囲
公開時点で OpenSSL 1.0.1〜1.0.1f は インターネット上のおよそ 17%(約50万台)の HTTPS サーバ に展開されていたと推定された(Netcraft、 University of Michigan の調査)。 Apache と nginx は OpenSSL に依存しており、 当時の Web サーバ市場で両者の合計シェアは2/3を超える。 つまり「インターネットの大半」が影響範囲だった。
加えて Heartbleed は クライアント側でも有効 だった。 OpenSSL を組み込んだメールクライアント、 VPN クライアント、 IoT デバイス、 Android 4.1.1 標準ブラウザ ── これらにも影響が及んだ。 修正パッチ適用、 すべての証明書のローテーション、 全ユーザのパスワードリセット、 全セッションの破棄 ── という大規模対応が、 公開直後の数週間にわたり世界中で進行した。
カナダ歳入庁では納税者900人分の社会保障番号が窃取され、 攻撃者が逮捕される実害も発生。 米セキュリティ研究者は、 NSA が公開前から Heartbleed を知って利用していた可能性を Bloomberg 経由で報じたが、 NSA は否定した。
なぜ2年間誰も気づかなかったか
事件後に明らかになった事実は、 OSS インフラの構造的問題を浮き彫りにした ── OpenSSL の主要メンテナはわずか1名のフルタイム(Stephen Henson)と、 数名のパートタイムボランティア で、 年間予算は当時2,000ドル程度の寄付に留まっていた。 一方で、 そのコードはインターネット商取引、 銀行、 政府通信のほぼすべての TLS 接続を媒介していた。 「単一障害点」がボランティア労働で支えられていた。
この異常な対比が、 OSS 持続可能性議論を一気に主流化させた。
余波 ── インフラ寄付モデルとフォーク
Core Infrastructure Initiative(CII): 公開からわずか17日後の2014年4月24日、 Linux Foundation の主導で Amazon、 Cisco、 Dell、 Facebook、 Fujitsu、 Google、 IBM、 Intel、 Microsoft、 NetApp、 Rackspace、 VMware らが共同出資する CII が発足。 OpenSSL に直接的な資金とフルタイム開発者を投入した。 CII は2020年、 Open Source Security Foundation(OpenSSF) に発展する。
LibreSSL: OpenBSD プロジェクトは OpenSSL のコードベースを「歴史的負債が大きすぎる」と判断し、 公開の数日後にフォークを宣言。 約1か月で約9万行のコードを削除する大規模リファクタリングを行った。
BoringSSL: Google は2014年6月、 内部利用向けに独自フォーク BoringSSL を公開。 互換性保証なしのため一般利用は推奨されないが、 Chrome、 Android、 Google サーバ群はこの派生に移行した。
法的側面: 一部の組織がリリース後の証明書更新と公開鍵ピンニング、 そして HSTS の必須化を急いだ。 また、 重要 OSS への「補助金的な企業出資」が ESG・ガバナンス文脈で説明可能な投資カテゴリとして定着し始めた。
残したもの
Heartbleed が示したのは、 「インターネットは、 ボランティアが書いた小さな C のライブラリに、 文字通り全体を依存している」 という現実だった。 同年に続く Shellshock(bash の脆弱性)、 2017年の Equifax 侵害(Apache Struts の脆弱性)、 そして2021年の Log4Shell(Log4j) ── これら一連の「OSS 単一障害点」事件の系譜の最初の項として、 Heartbleed は記録される。
「サプライチェーンセキュリティ」「SBOM(Software Bill of Materials)」「ソフトウェアサプライチェーン」 ── これらが業界の常用語になった起点も、 ここにある。