Heartbleed 2014年 OpenSSL の境界の確かめ漏れ

heartbeat の要求に書かれた長さを、受け取った記録の実際の長さと比べずに、その長さだけ複写して返した。仕様は長すぎる申告を黙って捨てよと書いていたが、コードにその1行が無かった。漏れるのは通信の中身ではなく、相手のプロセスのメモリで、秘密鍵も含み得る。

CVE-2014-0160。CVSS 3.1 の基本値は7.5、CWE-125 範囲外の読み取り[2]。影響は OpenSSL 1.0.1 から 1.0.1f と 1.0.2-beta1[1]。公表と修正の 1.0.1g は2014年4月7日[1][5]。TLS の heartbeat は 1.1.0 で除かれ、DTLS の heartbeat も 3.0.0 で除かれた[6]。2026年11月時点の公開資料で書いています。

何が起きたか

起きた仕組み

heartbeat は、TLS と DTLS の接続が生きているかを確かめる拡張である。要求を受けた側は、要求の payload をそのまま写して返す[3]。

struct {
   HeartbeatMessageType type;
   uint16 payload_length;
   opaque payload[HeartbeatMessage.payload_length];
   opaque padding[padding_length];
} HeartbeatMessage;

RFC 6520 は、送る側に16バイト以上の乱数の詰め物を求め、全体を2の14乗バイト以下とし、受け取った payload_length が大きすぎれば黙って捨てると定める[3]。payload_length は16ビットなので、申告できる値は最大65535になる。

• 勧告は、つないだクライアントにもサーバーにも、最大64KBのメモリが見える、と書く[1]。NVD は、細工した要求で範囲外の読み取りを起こし、秘密鍵を読めることが示された、と書く[2]。
• 読まれるのは、同じプロセスのメモリのうち、記録の後ろに続く物である。

架空の最小の例

架空の通信の echo の拡張で、同じ形の誤りを示す。1バイトの型、2バイトの申告の長さ、payload、16バイトの詰め物、の順の記録を受け、payload を写して返す。

直す前 申告の長さを確かめずに複写する

/* rec は受け取った記録の先頭、rec_len は記録の実際の長さ */
int echo_handle(struct conn *c, const unsigned char *rec, size_t rec_len)
{
    unsigned int claimed = (rec[1] << 8) | rec[2];   /* 申告の長さ */
    size_t out_len = 3 + claimed + 16;
    unsigned char *out = malloc(out_len);
    if (out == NULL) return -1;

    out[0] = ECHO_RESPONSE;
    out[1] = rec[1];
    out[2] = rec[2];
    memcpy(out + 3, rec + 3, claimed);   /* rec_len を見ていない */
    fill_random(out + 3 + claimed, 16);
    conn_send(c, out, out_len);
    free(out);
    return 0;
}

直した後 使う前に実際の長さと比べ、合わなければ捨てる

int echo_handle(struct conn *c, const unsigned char *rec, size_t rec_len)
{
    if (rec_len < 1 + 2 + 16) return 0;              /* 型と長さと詰め物も無い */
    unsigned int claimed = (rec[1] << 8) | rec[2];
    if (1 + 2 + (size_t)claimed + 16 > rec_len) return 0;   /* 黙って捨てる */
    size_t out_len = 3 + claimed + 16;
    if (out_len > MAX_RECORD_PLAIN) return 0;       /* 応答の上限 */
    ...
}

OpenSSL の修正も同じ形だった。ssl/t1_lib.c と ssl/d1_both.c で、型と長さを読む前に 1 + 2 + 16 が記録の長さを超えないか、読んだ後に 1 + 2 + payload + 16 が記録の長さを超えないかを確かめ、超えれば RFC 6520 の4節どおり黙って捨てる。応答の長さが記録の平文の上限を超えないかも確かめる[4]。

どこで止められたか

直した後の順

• 共有ライブラリを差し替えても、動いているプロセスは古い版を読み込んだままである。OpenSSL を結ぶサーバーのプロセスは、すべて再起動する。
• 鍵の作り直しは、修正を当てた後にする[8]。順が逆だと、新しい鍵も同じ穴から読まれ得る。
• 古い証明書は、作り直しても期限まで有効なまま残る。漏れた前提なら失効させる。
• セッションのクッキー、API の鍵、利用者のパスワードも、同じプロセスのメモリを通っていたなら漏れた前提で差し替える。

US-CERT は、あわせて Perfect Forward Secrecy を使うよう勧めた[8]。鍵の交換に使い捨ての鍵を使っていれば、サーバーの秘密鍵が後で漏れても、過去に記録された通信は復号できない。

守り方

AIが書く読み取りのコード

AIのコーディングの道具は、2進の形式を読む関数を短い指示で書く。申告の長さで複写する1行は、ふつうの入力で正しく動き、試験も通る。この件の誤りは、その形をしていた。

• 外から来た長さで memcpy、配列の添字、確保の大きさを決める行を、差分の中で探す。その前に実際の長さとの比較が無ければ止める。
• AIに試験を書かせると、正しい入力の試験に偏る。申告と実際が食い違う入力、上限ちょうど、上限を1超える入力を、人が足すよう指示する。
• 差分の読み方と、自動の点検を書く側と点検する側で分ける考え方は、AIの出力を確かめる にある。

参照

1. OpenSSL Security Advisory 07 Apr 2014, TLS heartbeat read overrun CVE-2014-0160 OpenSSL、2014年4月7日
2. CVE-2014-0160 NIST NVD
3. RFC 6520 Transport Layer Security and Datagram Transport Layer Security Heartbeat Extension IETF、2012年2月
4. Add heartbeat extension bounds check. openssl/openssl、2014年4月7日のコミット
5. NEWS openssl/openssl、OpenSSL_1_0_1-stable
6. CHANGES.md openssl/openssl
7. Support for TLS/DTLS heartbeats. openssl/openssl、2011年12月31日のコミット
8. OpenSSL Heartbleed Vulnerability CVE-2014-0160, TA14-098A US-CERT、CISA の保存版、2014年4月8日
9. OpenSSL の脆弱性に関する注意喚起 JPCERT-AT-2014-0013 JPCERT/CC、2014年4月8日、11日更新
10. Statement from the Interim Privacy Commissioner of Canada regarding Heartbleed カナダ個人情報保護コミッショナー事務局、2014年4月14日
11. Form 8-K, Item 8.01 Other Events Community Health Systems、米国証券取引委員会への届け出、2014年8月18日