Appleのgoto failバグ

何のコードか

2014年2月21日、Apple は iOS 向けに緊急のセキュリティ更新（iOS 7.0.6 と 6.1.6）と Apple TV 6.0.2 を配布しました。数日後の2月25日には OS X 10.9.2 が続きます。修正されたのは CVE-2014-1266、通称「goto fail」バグです。舞台は Apple 独自の TLS/SSL 実装 Secure Transport の中核、libsecurity_ssl/lib/sslKeyExchange.c にある SSLVerifySignedServerKeyExchange 関数でした。

この関数はサーバーが送ってくる Server Key Exchange メッセージの署名を検証する、TLS ハンドシェイクの心臓部です。にもかかわらず、たった1行の重複したコードのせいで署名検証そのものを素通りし、正しい署名も不正な署名も等しく受理していました。攻撃者は中間者（MITM）の位置に立てば、任意の TLS サーバーになりすまし、HTTPS で守られていたはずのログイン情報やメールを盗聴・改ざんできます。Apple のコードは公開されており、誰でも該当箇所を読めたことも、この事件が「1行がもたらした世界規模の危機」として語り継がれる理由です。

コードと仕組みの解説

横にスクロール

問題のコードは、ハッシュ計算の途中でエラーが出たら後始末へ飛ぶ、C言語の典型的な goto によるエラー処理でした。

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

/* ... この後に本来の署名検証が続く ... */

fail:
    SSLFreeBuffer(&signedHashes);
    SSLFreeBuffer(&hashCtx);
    return err;

goto fail; が2行連続しているのが分かります。C言語では if に波括弧を付けない場合、条件に従うのは直後の1文だけです。したがって1つ目の goto fail; は if に紐づきますが、2つ目はインデントで条件付きに見えても、実際にはどんな場合でも必ず実行される無条件の文です。

ここが致命的でした。2つ目の goto fail; に到達するのは、直前の SSLHashSHA1.update が成功して err に0（成功）が入っている場合です。そのまま fail: ラベルへ飛び、err（＝0）を return します。呼び出し側は戻り値0を「検証成功」と解釈するので、その先に書かれていた本命の署名照合コードは一度も実行されません。SHA1 の更新に成功しさえすれば、署名が正しかろうと偽物だろうと、関数は常に「OK」を返してしまうわけです。

goto を使うこと自体が悪だという俗説がありますが、これは誤りです。リソース解放を1か所に集約する goto fail 型のエラー処理は C言語では定番で、Linux カーネルでも広く使われます。真犯人は goto ではなく、波括弧の省略と、コードの重複による混入でした。

逸話と経緯

正確な混入時期は今も特定されていません。分かっているのは、2012年5月公開の iOS 5.1.1 には無く、2012年9月公開の iOS 6 には存在したこと。つまり脆弱性はおよそ1年半、誰にも気づかれず iPhone や Mac の中で動き続けていました。誰が余分な1行を書いたのか、Apple は公式に明かしていません。マージ時のコンフリクト解消でコピー＆ペーストがずれた、といった推測はありますが確証はなく、事実として語れるのは「重複した1行が入った」という結果だけです。

2014年2月21日の iOS 修正が引き金でした。セキュリティ研究者たちが公開済みのソースと差分を突き合わせ、原因がこの1行だと即座に特定します。ところが Apple は iOS を先に、OS X 版を数日遅れで出したため、Adam Langley をはじめとする研究者が該当コードを解説した時点で、Mac は未修正のまま脆弱性が世界に周知されるという危うい状況が生まれました。修正前のブラウザで動作を試せる gotofail.com が公開され、話題はさらに広がります。

遺産と教訓

この事件が突きつけたのは、なぜ混入から発見まで1年半もかかったのかという問いです。答えは開発プロセスの複数の穴にありました。

まずコンパイラ警告。2つ目の goto fail; の後ろにある if 文は決して実行されない到達不能コード（dead code）です。Clang には -Wunreachable-code があり、これを有効にしていれば警告できました。しかし当時この警告は -Wall（全警告）に含まれておらず、既定では黙殺されていたのです。後に GCC 6 は、まさにこの手のミスを狙った -Wmisleading-indentation（インデントが構造と食い違う場合の警告）を追加しました。

そして最大の教訓はテストです。この関数は外部依存を差し替えれば単体テスト可能で、不正な署名を1件でも投げれば必ず露見しました。「正しい入力を受理する」正のテストだけでなく、「不正な入力を拒否する」負のテストが欠けていたのです。加えて文カバレッジ（statement coverage）を計測していれば、本来の検証コードが一度も実行されていない事実が数字で見えました。同じハンドシェイク処理のパターンがコード内で何度も複製されていた点も、混入の温床でした。

TLS ハンドシェイクと証明書検証の原理はセキュリティを、静的解析やコードレビューを含む堅牢な開発手法はプログラミングを参照してください。

一段で言うと

たった1行の重複した goto fail; が、iPhone と Mac の HTTPS を1年半にわたり無防備にしていました。C言語の波括弧省略という古典的な罠に、有効化されていない警告、欠けた負のテスト、計測されないカバレッジが重なった結果です。犯人は goto でも一人の開発者でもなく、1行の混入を無害化できなかった開発プロセスそのもの——それがこの1行が今も教え続ける教訓です。