第14回:バッファオーバーフローとサーバ側のセキュリティ対策を考える (2/3)

オープンソースの適用可能性を示す
オープンソースの適用可能性を示す

第14回:バッファオーバーフローとサーバ側のセキュリティ対策を考える
著者:芝 国雄   2006/9/5
前のページ  1  2   3  次のページ
バッファオーバーフローは頻発するバグの1つ

   次に、Webアプリケーションのセキュリティについて考える。読者の皆さんは「バッファオーバーフロー」という言葉をご存知だろうか。また言葉は知っていても、それがどのような仕組みで悪意のある攻撃に使われるかは、あまりよく知られていないので簡単に触れておく。

   バッファとは、プログラムを実行する際に使用するメモリ上の領域のこと。通常は、プログラムコードでどれだけの領域を使うか指定するが、何かの原因で指定した領域以上のメモリを使ってしまう(領域からあふれてしまう)ことをバッファオーバーフローと呼ぶ。その際、あふれてしまったメモリ領域を他のプログラムが使用していたら、そのプログラムは予期しない動作をしてしまう。

   攻撃者は、故意にバッファオーバーフローを起こし、悪意のあるプログラムコードをあふれた領域にロードして、そのプログラムを実行するわけだ。

   一方で、悪意の有無を問わずバッファオーバーフロー自体が、プログラムコードに内在するバグ(セキュリティーホール)のうちもっとも多いものの1つという事実がある。

   そこで、このようなセキュリティホールが存在するプログラムコードを実行しても、被害を最小限に抑えられるOSSを紹介する。

   まずは「StackGuard」だ。これは、「カナリア」と呼ばれるランダムな値をスタックの戻りアドレスの直前に挿入。関数の実行後、カナリアが戻りアドレスにジャンプする前にチェックすることで、バッファバッファオーバーフローを検知する。

   また、IBMの「Stack-Smashing Protector」は、日本IBMで研究・開発されている技術で、基本的にはStack-Guardと同様の機能を備えている。


   次は「Bounds Checking」だ。これはプログラムコード中にチェック機能のためのコードを埋め込んでプログラムを保護する。詳細は以下のサイトを参照してほしい。


   3番目は「Libsafe」。バッファオーバーフローなどのセキュリティ上の問題を回避するためのC言語のライブラリと言える。プログラムコードを変更する必要がないので、既存のシステムにもそのまま適用できるだろう。

   これらの製品は大きく2つに分類できる。「コンパイラを拡張するタイプ」と「ライブラリを拡張するタイプ」だ。前者を使用する場合、プログラムを保護するためには、拡張したコンパイラでプログラムを再コンパイルする必要がある。前述の「StackGuard」や「Stack-Smashing Protector」「BoundsChecking」がこのタイプだ。

   一方後者は、プログラムの実行時に、脆弱性のあるC言語の関数を自動的に変換する。例えば、strcopy()関数はstrncopy()関数に、strca(t)関数はstrnca(t)関数に変えるわけだ。Libsafeがこちらに該当する。

   この手法の違いで注意しなければならない点は、前者はプログラムコードがなければ使えないということだ。コンパイラを拡張するOSレベルの権限を持っている必要があるわけだ。


セキュリティホールになるプログラムコードの排除が肝要

   もちろん、これらのツールを使っても、セキュリティホールをすべてカバーすることはできない。そのためもっとも初歩的だが、セキュリティホールになるプログラムコードを書かないことが根本的対策ともいえる。

   ここで登場するのが、プログラムコードを検査するツールだ。プログラムコードを検査するツールには、「パターンマッチング」と「構文解析」の技術を使った2種類がある。

   ここでは、パターンマッチング技術を採用した「RATS」(RoughAuditing Tool for Security)を紹介する。RATSは、米国セキュアソフトウェア社によって開発されたOSSだ。

   RATSでは、CやC++、PHP、Perlなどのプログラム言語を検査できる。RATSが保持するセキュリティホールの情報が記録されたデータベースを使って検査する。このデータベースの情報はユーザによって拡張することもできるようだ。

   以上、OSSのセキュリティ対策ツールを見てきた。

   情報システムにはセキュリティ対策が必要だという認識は誰もが持っているが、その対策には「正解」も「完璧」もない。ウィルスやワーム、セキュリティホールを狙った攻撃は、次々に新手が出現する。これに対応するためには、セキュリティの情報を日々収集し、それにあわせて継続的に対策を見直していくことが大切だ。

前のページ  1  2   3  次のページ

イーシステム株式会社 芝 国雄
著者プロフィール
芝 国雄
1995年、日本グプタ(現イーシステム)入社。米グプタ社製品の統合開発ツールの「Team Developer」、RDBMSの「SQLBase」といった製品の日本語化をはじめ技術支援や販売、マーケティング業務に従事。主に、ユーザ企業のシステム開発の現場で、システムの設計に関わる事前調査や助言などの上流工程から、プログラミング時のトラブルシューティングまで、幅広く支援していた。2000年4月、携帯電話を活用したワイヤレスソリューション事業の立ち上げに従事。現在は新しいチャレンジに向け充電中。


INDEX
第14回:バッファオーバーフローとサーバ側のセキュリティ対策を考える
  はじめに
バッファオーバーフローは頻発するバグの1つ
  本番運用に近い環境で検証する必要性を実感
オープンソースの適用可能性を示す
第1回 ユーザ企業におけるOSS浸透のカギはメインフレーム世代のSE
第2回 DB管理ツールを例にOSSの現在の実力を診断する
第3回 OSSはビジネスになるのか?「魔法のお鍋」を読み直す その1
第4回 OSSはビジネスになるのか?「魔法のお鍋」を読み直す その2
第5回 OSSはビジネスになるのか?「魔法のお鍋」を読み直す その3
第6回 OSSはビジネスになるのか?「魔法のお鍋」を読み直す その4
第7回 PostgreSQLを使い切るためのノウハウを徹底解説する その1
第8回 PostgreSQLを使い切るためのノウハウを徹底解説する その2
第9回 PostgreSQL vs MySQL2つのDBMSを検証する(前編)
第10回 PostgreSQL vs MySQL2つのDBMSを検証する(後編)
第11回 OSSのプロがいなくても大丈夫!必要なソフトの情報はこうして探す(前編)
第12回 OSSのプロがいなくても大丈夫!必要なソフトの情報はこうして探す(後編)
第13回 クライアントのOSとしてLinuxを検証する
第14回 バッファオーバーフローとサーバ側のセキュリティ対策を考える

人気記事トップ10

人気記事ランキングをもっと見る