バッファオーバーフローは乗り越えられるか? JPNIC/JPCERT/CCセミナー(2/2 ページ)

» 2004年10月06日 16時39分 公開
[高橋睦美,ITmedia]
前のページへ 1|2       

 では、バッファオーバーフローを引き起こさないようにする方法はあるのだろうか。古賀氏によると、まず境界チェックをしっかり行い、getsや(v)scanfといった危険な関数はできるだけ使わないようにすべきだという。また、StackGuardlibsafeといったツールを用いることで、アドレスの書き換えを監視し、スタック領域でのコマンド処理を禁止することも可能だ。

 古賀氏は、「こうした対策を取ったからといって完全に脆弱性をなくせるわけではない。だが、これらの対処を行うだけでもかなり安全なレベルになる」と述べている。ただし対処の結果、既存のアプリケーションの挙動に影響が出るなどの副作用が生じる可能性もある点に注意が必要という。

脆弱性がワームに転化する条件

 続く新井氏は、Windowsの世界に絞ってバッファオーバーフローについて説明した。同氏は経験則に応じて、「スタックオーバーフローは、すべてのバージョンや言語に効くという意味で汎用性が高く、攻撃が成功する確率は高い。実際いくつかのワームにも悪用されている。これに対しヒープオーバーフローはいくつか条件が重ならないと攻撃が成功しない」と指摘した。

 しかしながら、過去の苦い経験を経て多くのスタックオーバーフローは修正され、「もうほとんど見つからなくなった」(同氏)。これに対し、攻撃者の技量が向上したこともあって、最近ではヒープオーバーフローが主流になりつつあるという。

 新井氏はさらに、ワームとバッファオーバーフローの関係性についても言及した。同じバッファオーバーフローでも、ワーム化して大きな被害を与えるものとそうでないものとがあるが、これにはいくつかの要素が関係してくるという。1つは、リモートから攻撃が可能かどうかという点だ。また、攻撃成功に必要な権限や攻撃の経路(TCPかUDPか)、ペイロードの大きさなども影響を与えるという。

 こうした要素を踏まえると、「一番シリアスなのは、UDPを用いてリモートからの攻撃が成功するようなバッファオーバーフロー」(新井氏)。逆に言えば、仮にリモートからの悪用が不可能な脆弱性ならば、認証やファイアウォールの設定変更など他の手段でしのぎ、パッチ適用を先延ばしにする、という判断も合理的なものになる。

 とはいえ最近では、脆弱性が発見されてから攻撃が開始されるまでの日数が短縮化するどころか、パッチの公開前に攻撃が行われる、いわゆるゼロデイ状態まで登場してきた。このように「ワームやウイルスのほうが先に出回る時代」には、プロアクティブなバッファオーバーフロー対策が必要だという。

 その1つとして紹介されたのが、Visual C++ .NETなどで加わった「/GSオプション」だ。これはStackGuardと同じような考え方で作られた機能で、リターンアドレス(戻り値)が上書きされていないかどうかを確認し、問題があるときにはその処理を中断するという仕組みだ。

 もう1つは、Windows XP Service Pack 2で加わった「DEP(Data Execution Prevention)」である。これはハードウェア(一部のAMDおよびItaniumのプロセッサでしか実装されていない)およびソフトウェアの両方でバッファオーバーフローを防ぎ、コードの実行を阻止する仕組みだ。

 ただ、この仕組みのうちソフトウェアDEPはXP SP2の適用で今すぐ利用できるが、ハードウェアDEPを利用するにはCPUのアップグレードなど追加投資を行う必要がある。このため、現時点でDEPの恩恵にフルにあずかれるユーザーは、残念ながらそう多くはない。今後の普及に期待したいところだ。

 新井氏は最後に、「バッファオーバーフローによるコード実行を抑止する機構は実装されつつあり、今後はワームの被害も少なくなるかもしれない」と期待を述べた。ただ一方で、今はまだ過渡期であり、「特にWindows 98などレガシーなシステムをいっせいにリプレイスするのは不可能」なことから、当面は警戒を緩めることができないのも事実という。

前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ