発見企業が語る、Heartbleedの残した「教訓」：コードテストの重要性が浮き彫りに

「Heartbleed」脆弱性を発見した企業の1つが、フィンランドのセキュリティ企業、Codenomiconだ。同社の極東事業開発ディレクター、チャンギュウ・キム氏に経緯を聞いた。

[高橋睦美，＠IT]

　OpenSSLに発見された「Heartbleed」の脆弱（ぜいじゃく）性を受けて、多くの企業がバージョンアップ、SSLサーバー証明書の失効処理および再発行、ユーザーへの呼び掛けといった対策を進めている。インターネット上のWebサイトを解析しているAlexa Internetがまとめている利用者数の多いWebサイトを示すリストを基にシマンテックが調査を行ったところ、上位1000サイトは既に対策済みで、上位5万サイトに範囲を広げても、脆弱なシステムは1.8％程度にまで減少しているということだ（関連記事）。

Codenomicon 極東事業開発ディレクター チャンギュウ・キム氏

　この脆弱性は、米グーグルと、フィンランドのセキュリティ企業であるCodenomiconがそれぞれ独自に発見した。

　Codenomiconはもともと、プロトコルの脆弱性を検査するファジングツール「DEFENSICS」などを開発、提供している企業だ。同社の極東事業開発ディレクター、チャンギュウ・キム氏によると、Heartbleedは、脆弱性検査ツール「Safeguard」で自社Webサーバーを検査していた際に見つかったという。グーグルとほぼ同時期に発見したのは偶然とのことだ。

　　HeartbleedはOpenSSLのバージョン1.0.1／1.0.2系に存在する。Heartbeat拡張の実装に問題があり、通信相手からメモリ上の情報を盗み見られてしまう。タイミングによっては、SSL通信用の秘密鍵やセッション情報などが漏えいする恐れがある。

　この脆弱性について検証した「Cloudflare Challenge」の報告によれば、システムの状態やタイミングによって、メモリ上の情報を抜き取るまで10万回、あるいは250万回という試行を繰り返す必要があったという。

　一方で、IIJ-SECT（IIJ group Security Coordination Team）のブログによれば、これまでの暗号研究の成果によって、秘密鍵を奪取するには「PKCS#1形式（RSA標準の暗号鍵フォーマット）のデータ全てを取得する必要はなく、その一部の情報からでも秘密鍵が奪取できたと考えることができる」という。つまり、秘密鍵ファイル全体を復元するために、何度もアクセスを繰り返して力ずくで奪わなくても、「もっと少ない試行回数で断片情報から秘密鍵が復元されてしまう可能性がある」（同社ブログ）ということだ。

　Codenomiconのキム氏も、重要な情報を盗み出すには多くのアクセスを試す必要があるため難しく、必要以上におびえる必要はないとしながらも、「だからといって“大丈夫”とは言えない」と述べる。同社ではこの脆弱性の深刻さを踏まえ、発見後、フィンランドのナショナルCERTに報告した。

リリース前のテストを

　見つかってみればHeartbleedは、メモリコピー処理の実装で境界チェックを怠ったという単純なミスに起因する脆弱性だ。だが、こうした単純ミスによる脆弱性は今回が初めてではない。

　例えば2014年2月、アップルのiOSとOS XのSSL／TLSに関して情報漏えいにつながる深刻な脆弱性が見つかり、修正された。ソースコードを解析した結果、この脆弱性は、おそらくプログラマーの“コピペミス”に起因するものと見られている（関連記事）。

　こうした事実を踏まえると、「コードを書く上で、ミスは当然あるという前提でチェックをすべき」とキム氏は述べる。

　Heartbleedはたまたま最新のバージョンにのみ存在する脆弱性だったが、今回の問題が浮上したからといって、古いバージョンを使い続けるべきなどとは全く言えない。むしろ、見つかった脆弱性は氷山の一角であり、今後もさまざまなアプリケーションのさまざまなバージョンに脆弱性が含まれている可能性があるという前提に立ち、検査を実施していくべきという。

　それも「コードが短いうちは開発者全員でレビューしても大きな問題はないだろうが、何千行、何万行と長くなってくれば、ツールを使って外からテストしていく必要がある。自動化できるところは自動化していくべきだ」（キム氏）。

　しばしば言われることだが、サービスにせよソフトウェア製品にせよ、リリース後に脆弱性に対応するよりも、開発段階からセキュリティを考慮し、チェックしていく方が、コストを低く抑えることができる。それも、出荷直前のぎりぎりの段階でチェックするよりも、設計段階からセキュリティを考慮することで、漏れなく検査できる。

　さらにこのとき、既知の脆弱性はもちろん、多数のテストケースを実施して未知の脆弱性にも備えるべきとキム氏は言う。「ネットワークに接続されるアプリケーションや機器は、想定外の事態に直面すると考えるべき。想定外のこと、想定しなかった環境に置かれるという前提でチェックしないといけない」（キム氏）。

　Codonomiconはまた、1組織内、1企業内でのチェックから一歩進んで、調達プロセスにもセキュリティという要素を組み入れていくべきだと考えている。例えば米ベライゾンなどは、外注先から納品されるコンポーネントについて「脆弱性検査をクリアしない限り検収しない」「ファジングテストを受けていないものは受け付けない」という、セキュア・プロキュアメントを導入している。こうした取り組みによって、エコシステム全体のセキュリティ向上につながる。

　同氏が今懸念しているのは、重要インフラを支える制御システムや医療機器といった、いわゆるITシステム以外の分野の脆弱性だ。こうした分野においても、テストの重要性はますます増していくだろうと予測する。

　「モノを作る人や会社は、自社の信頼性を高めるために、リリース前に品質だけでなく脆弱性のチェックも行わないといけない」（キム氏）――ごくごく当たり前のことだが、Heartbleedの一件はこの鉄則を改めて突きつけたといえるだろう。