危険度はバッファオーバーフロー級セキュリティの深刻な脆弱性につながるダングリングポインタ
ダングリングポインタは品質管理段階まで放置すると取り返しがつかなくなる恐れがあるため、開発ライフサイクルの早い段階から回避策を実行する必要がある。
従来、ダングリングポインタという非常に一般的なプログラミングエラーは、セキュリティの問題というよりも品質管理の問題と考えられることが多かった。例えば、2005年にInternet Information Services 5.1のダングリングポインタがMicrosoftに報告されたが、その後2年間、対応パッチが提供されなかった。こうしたバグはシステムをクラッシュさせたり、深刻なセキュリティ上の脅威をもたらす可能性があるにもかかわらずだ。
ダングリングポインタは、プログラマーがメモリオブジェクトを作成・使用し、解放時に、オブジェクトのポインタの値をそれに合わせて変更（つまり、NULLに変更）しなかった場合に発生する。そのポインタは、メモリの割り当てが解除されたメモリ位置を不正に参照することになる。このポインタがダングリング（宙ぶらりん）ポインタと呼ばれるのは、このポインタが指すメモリが、もはや有効なオブジェクトを保持していないかもしれないからだ。このメモリはまったく異なるデータを含んでいる可能性があるため、オブジェクトにアクセスするためにプログラマーが誤ってこのポインタをデリファレンスする（ポインタが指す値を参照する）と、予測できない動作が発生する恐れがある。
最近IBMに買収されたオンラインリスク管理会社Watchfireの専門家は、ダングリングポインタをコントロールして、特定のメモリ位置を参照させる方法を発見した。同社研究員のジョナサン・アフェク氏とアディ・シャラバニ氏は、特別に作成されたURLをサーバに送信することでターゲットマシンをクラッシュさせ、その上でシェルコードを実行できる場合があることを確認した。攻撃者はこの方法により、バッファオーバーフローの脆弱性を悪用する場合とほぼ同様に、ダングリングポインタの問題があるアプリケーションが動作する任意のマシンを、リモートでコントロールしたり破損させたりすることができる。
バッファオーバーフロー攻撃がいかに大きな実害をもたらすかは周知の通りだ。データ構造の破壊、情報の流出、権限の昇格、悪意あるコードの実行。これらはいずれも、攻撃者がコンピュータのメモリを不正に操作することで引き起こす可能性があるトラブルだ。ダングリングポインタは、成熟したアプリケーションのほとんどで見つかる可能性が高い問題だが、ハッカーが主に狙うのはWebサーバアプリケーションだろう。Webサーバアプリケーションには大量の機密データが含まれる場合が多いからだ。
プログラマーにとってダングリングポインタは非常に発見しにくい。多くの場合、ダングリングポインタが無関係なデータを破損したりシステムを不安定化させたりするのは、作成されてからかなりたった後だからだ。このバグは、CやC++のような比較的低級な言語で作成されたアプリケーションでよく見られる。JavaやC#のようなより高級な言語では、ダングリングポインタは発生しない。こうした言語ではポインタが自動的に管理され、オブジェクトが削除されるとガーベジコレクションが暗黙的に行われるからだ。何らかの形でポインタを自動的に管理する機能を持たない言語を使用する開発者は、アプリケーション開発プロセスを再検討する必要がある。ポインタはすべて、使用した後でNULLポインタに設定するようにしなければならない。
メモリを適切に管理する手段として広く使われているのがスマートポインタだ。スマートポインタでは通常、参照カウントを利用してオブジェクトを解放する。参照カウントは同一オブジェクトを参照するスマートポインタの数をカウントし、カウントがゼロになるとオブジェクトが削除される仕組みだ。
ダングリングポインタの回避策としては、「トゥームストーン方式」や「ロックアンドキー方式」も利用できる。トゥームストーン方式では、オブジェクトが消滅すると、関連付けられたトゥームストーン（墓石）が、そのオブジェクトを参照している可能性があるすべてのポインタを自動的にNULLにする。ロックアンドキー方式では、順序キーのペアの2つの値を比較することで、ポインタアクセスが決定される。また、デバッグツールスイートのValgrindやコードをクリーンアップするBoehm-Demers-Weiserガーベジコレクタのようなツールも、ダングリングポインタ問題の防止に役立てることができる。
ダングリングポインタは、もはや決して軽視できない問題となっている。開発者はソフトウェア開発プロセスの整備を徹底し、ダングリングポインタが本番コードに含まれないようにしなければならない。この問題は、品質管理段階まで放置すると取り返しがつかなくなる恐れがあるため、開発ライフサイクルの早い段階から回避策を実行する必要がある。高級言語を使用すれば、回避プロセスは比較的シンプルなものになるだろう。ほかの言語でプログラムを開発・保守している開発者には、以上に述べたベストプラクティスを導入することをお勧めしたい。
本稿筆者のマイケル・コッブ氏は、データセキュリティおよび解析に関するトレーニングやサポートを提供するITコンサルティング会社、Cobweb Applicationsの創業者兼マネージングディレクター。CISSP-ISSAP（公認情報システムセキュリティプロフェッショナル―情報システムセキュリティアーキテクチャプロフェッショナル）の資格を持つ。共著書として「IIS Security」があり、主要なIT出版物に多くの技術記事を寄稿している。
この記事を読んだ人にお薦めのホワイトペーパー
この記事を読んだ人にお薦めの関連記事
ITmediaはアイティメディア株式会社の登録商標です。