バッファとは？
|
バッファオーバーラン (buffer overrun) とは、コンピュータのプログラムのバグによって起こる、コンピュータの望ましくない動作の一つである。バッファオーバーフロー (buffer overflow) とも言う。 バッファオーバーランはコンピュータセキュリティ上の深刻なセキュリティーホールとなりうるため、バッファオーバーランが起こる可能性のあるコンピュータプログラムはすぐに修正する必要がある。 バッファオーバーランは、バグによってデータでバッファ領域の内外を上書きしてしまい、誤動作を引き起こす。そうした場合、通常はそのプログラム（ないしオペレーティングシステム）が動作不安定になりまたは停止するが、しばしば、そのようなバグのあるプログラムに対して、意図的なデータ（悪意のあるコード）を与える事により、コンピュータの動作を乗っ取ってしまう事が問題となる。 バッファオーバーランはその上書きする領域の種類によって、スタックオーバーラン、ヒープオーバーランに大別される。 スタック、ヒープのいずれもプログラムの実行に不可欠なデータ（例えばサブルーチンのリターンアドレスや、ヒープ内のコード）を内包する事があり、そのようなデータを意図的に上書きさせることにより、意図的なコードを実行させることが可能になる。 コンピュータプログラムを作るとき、固定長のバッファとよばれる領域を確保してそこにデータを保存するという手法がよく使われる。 これがバッファオーバーランである。仮にはみ出した部分にプログラムの動作上意味を持つデータがあれば、これを上書きして破壊することにより、プログラムはユーザの意図しない挙動を示すであろう。 このようにバッファオーバーランは、プログラムが用意したバッファの大きさを超えてデータを書き込んでしまうバグである。 C言語の標準入出力関数であるgets関数はバッファ長のチェックを行わないで標準入力をバッファに書き込むので、この関数を使う全てのプログラムには、バッファオーバーランによる不正動作の危険性がある。また使い方が分かりやすいという理由でC言語初心者向けの入門プログラミングでしばしば用いられるscanf関数も同じ危険性を持っている。これらの関数を実用的なプログラムで用いてはならない。 次のプログラムはgets関数を用いた例である（セキュリティ上、gets関数はそれ自体をテストする以外の目的で使用されるべきではない。Linux Programmer's Manualには「gets()は絶対に使用してはならない。」と書かれている）。バッファ長として200バイト確保されている。gets関数はバッファの長さについては関知しないため、200バイトを超えても改行文字かEOFが現れなければバッファオーバーランが発生する。 例えばgets関数の代わりにfgets関数を用いることで、この問題を回避できる。次のプログラムは上記のプログラムと等価である。fgets関数にはバッファのサイズを渡すことができ、このバイト数を超えてバッファに書き込みを行わない。従ってバッファサイズが正しく設定されていれば、fgets関数においてバッファオーバーランは起こり得ない。 オペレーティングシステム(OS)によっては、プログラムのコード領域とデータ領域を区別せず、コードがデータ領域に書かれていてもそのまま実行してしまう物がある。 もっとも典型的なバッファオーバーランは、データ領域のうちでもスタック領域に対するものである。前述のバッファがスタック領域に割り当てられたものである場合（この割当てはC言語の自動変数で典型的である）、はみ出したデータがスタック領域の当該バッファ割当て部分よりも外の部分を書き換えてしまう。一方、スタック領域にはプログラムカウンタにリストアされるべきサブルーチンからのリターンアドレスが格納されているが、そのリターンアドレスをバッファーオーバーランしたデータで書き換えてしまう事になる。 バッファーオーバーラン等の不正動作に対する保護機能が無いようなOS上で実行されるアプリケーションソフトウェアでは、プログラム作成者ないし利用ユーザの意図の有無に関わらず、常にこの危険性を含んでいる。現在大衆向けに販売されているOSの多くは、このようなメモリ保護機能を持たない事が問題の根底にある。 クラッカーは、このバッファオーバーランを意図的に起こしてデータの改竄やコンピュータシステムの損壊につながる操作をおこなう（通常は、ワームウイルス等の不正プログラムを作成し、それに攻撃を実行させる）。 通常は、不正アクセスの手段として不正なデータをコンピュータに対して送信すると言う事があるが、バッファオーバーラン攻撃を行う場合には、送信データに不正なプログラムのコードを挿入し、さらに前述のスタック領域上のリターンアドレス等を、この不正コードが存在するアドレスに書き換える事等により、任意の不正なコードを相手のコンピュータにおいて実行させ、OS上の管理者権限を不正に奪取するなど様々な攻撃を行う。 近年、コンピュータの制御を乗っ取り、攻撃を行うウイルスはバッファオーバーランを利用した物が多い。脆弱性を示す為に作られたプログラムExploitを悪用し、そのプログラムにウイルス機能を載せた物が大多数を占める。2003年8月インターネットトラフィックにおいてバックグラウンドノイズとされるトラフィックが1kbps未満から突然30〜40kbpsに跳ね上がった。これはWindowsのRPCサブシステムにおけるバッファオーバーランによるセキュリティホールを攻撃し、制御を乗っ取り自らウイルスを放出するMSBlastウイルスによる攻撃が全世界規模で発生した為である。 C言語でかかれ、古いライブラリ関数を多用している、そして多くの文字列処理を行っている、"sendmail"プログラムは近年こそ毎年のペースまで下がったが、以前は毎月のようにバッファオーバーランによるセキュリティホールが発覚し、修正されていた。そしてsendmailを突破口としてセキュリティを破られたシステムはとても多く、その数はWinnyによる情報流出を上回るものである。このようなセキュリティ上の観点から（またライセンスの関係もあるが）sendmailを標準プログラムから排除する動きがあり、いくつかのOSディストリビューションの標準セットからsendmailは取り除かれてしまった。 バッファオーバーランは潜在的に大量に存在する問題であり、その対策のために多くの研究が行われているが、いまだに決め手となる技術は存在していない。 バッファオーバーランをおこすソフトウェアの多くは C言語などコンパイラ言語で書かれているため、自動的なチェック機構を導入すると深刻な性能低下をひきおこすことが多いためである。 アドレスランダム化 (address randomization) の技術は、バッファオーバーランが本来メモリ中の特定の位置にプログラムに配置されていることを前提としていることから、メモリ構造を並べ替えて外部の攻撃者が予測不可能にするものである。また、Linux などの OS では一度メモリに書かれた領域をマークしておき、その部分を実行禁止にするという技術 (PaX) も導入されている。しかしこの 2つをもってしても、クラッカーが巧みにメモリをスキャンすることで攻撃が可能になってしまう例があることが示されている。いっぽう、プログラムのソースコードを静的にチェックすることで、事前に明らかなバッファオーバーランの可能性がある場合は警告を発するなどのシステムも研究されている。しかしこの場合もすべてのエラーを発見できるわけではない。 その他の対応としては、適切なメモリ保護機能を持ったOSやCPU（例えば、データ領域のデータをコードとして実行させないなど）を使用するか、または、実行時に常にバッファオーバフローを検知する機能や仕組みを、利用するかまたは自ら実装する事が、根本的解決方法である。このような機能を備えた環境を整備できない場合、常にバッファ長を意識したプログラムを書くよう努力し、見落としがあった場合はあきらめるしかない。 メモリ保護機能の実装例の一つとして、完全なハーバードアーキテクチャのハードウエアとオペレーティングシステムの組み合わせが考えられる。この構成はバッファーオーバーランの脅威を緩和する。データ領域におかれた任意のコードを実行する手段が無いからである（プログラムを異常動作させる事は可能であろう）。これと同程度の保護を実現する手段としてAMD社が開発したAMD64 Enhanced Virus Protectionがある。これはWindowsXP SP2と組み合わせて利用する事により、ページ単位でコード領域とデータ領域を区別し、バッファーオーバーランの脅威を軽減している（AMD社製品ではOpteron、Athlon 64、Turion 64、Sempronの一部製品がこれに対応している。Intel社製品ではXD・eXecute Disable Bitという名前で同じ機能を実装しておりNetBurstアーキテクチャPentium4ファミリにおいてIntel 64対応プロセッサで利用できる。またCoreマイクロアーキテクチャの全てのプロセッサでは標準装備となる見通しである）。ただし、WindowsXP SP2はこのセキュリティ強化を含めて多くのセキュリティホールを修正した結果互換性に問題が生じた為、大手企業ではSP2の導入に消極的である。 インタプリタ言語には、配列の確保領域外へのアクセスを処理系が自動的にチェックするものが多いため、配列によるバッファに対するバッファオーバーランが発生しにくい（インタプリタ言語ではエラーメッセージを出して動作が停止するが、コンパイラ言語ではそのまま実行し不正動作を起こす）。ただし、インプタプリタそのものはほとんど例外なくコンパイラ言語によって書かれているので、絶対に信頼できるわけではない。また言語に付属するライブラリやモジュールは母体となった言語のライブラリやシステムコールに由来し、脆弱性が組み込まれてしまうこともある。 配列領域をチェックする機能は16bit時代から、80x86CPUのBOUND命令など既に実装されていたが、チェックの結果問題があった場合には例外を発生させる等扱いが難しかった。現在のCPUにおいてもチェックにまつわるオーバーヘッドが無視できないので、リリースバイナリにこれらの機能を含めることはまれである。 現在、バッファオーバーランはもっとも重大なセキュリティーホールのひとつと考えられているため、あるプログラムでバッファオーバーランの脆弱性が発見されると、一般にそれに対する修正作業の優先度は非常に高く、プログラムの更新バージョンの公開や修正プログラムの配布などが行われる。 なお2006年4月21日情報処理推進機構(IPA)は、P2Pデータ交換ソフトWinnyにおけるバッファーオーバーランによる脆弱性を発表した。この発表に基づき、いくつかのセキュリティ調査会社はこの脆弱性が適切なデータを用意する事で任意のコードを実行する事が可能である事を報告した。しかしソースコードが京都府警ハイテク犯罪対策室によって押収されている為プログラムの修正が出来ないので、この脆弱性に対する対策は「Winnyを使用しない事」とされた（その後リバースエンジニアリングによってWinny利用者による修正バージョンが配布された）。 |
[ 134] バッファオーバーラン - Wikipedia
[引用サイト] http://ja.wikipedia.org/wiki/%E3%83%90%E3%83%83%E3%83%95%E3%82%A1%E3%82%AA%E3%83%BC%E3%83%90%E3%83%BC%E3%83%A9%E3%83%B3
|
バッファ・オーバーフローに起因するセキュリティ・ホールは後を絶たない。バッファ・オーバーフローの脅威は，攻撃者に任意のコードを実行されてしまうことだ。セキュリティ・ホールがあるプログラムへのパッチ適用などが第一の対策ではあるが，ユーザー側でバッファ・オーバーフローの発生を抑制して，その影響を最小限にとどめる方法もある。OSカーネルのオプションやライブラリ，コンパイラの変更である。今回のコラムではそれらを紹介する。 ここ最近，Apache/mod-sslのセキュリティ・ホールを利用して伝播する「slapper」ワームが出回り始めている。このワームに関しては9月17日にJPCERT/CCからも警告が発せられている（関連記事）。このワームは，OpenSSLに存在するバッファ・オーバーフローのセキュリティ・ホールを悪用する。 バッファ・オーバーフローに起因するセキュリティ・ホールは枚挙にいとまがない。例えば，最近では以下のセキュリティ・ホールが見つかっている。 バッファ・オーバーフローを悪用した攻撃が危険なのは，攻撃者が意図する命令をぜい弱性があるマシン上で実行されてしまうからである。 バッファとは，プログラムが処理を行う際に使用する，一時的にデータをためるためのメモリー上の領域のことである。通常は問題がないものの，プログラムで指定したサイズ以上のデータが入力された場合などには，バッファ領域が“あふれて”しまう。これがバッファ・オーバーフローである。あふれたデータはバッファ領域以外に上書きされる。そのため，プログラムを暴走させられたり，任意のコードを実行されたりすることになる（詳細は日経Linuxの「Linux Q & A」などを参照のこと）。 バッファに書き込む前に，プログラムがデータのサイズをきちんとチェックしていればバッファ・オーバーフローは防げる。しかし実際には，適切なチェックを行っていないソフトウエアが多数あるために，次から次へとバッファ・オーバーフローに起因するセキュリティ・ホールが見つかるのである。 では，次々見つかるバッファ・オーバーフローに，システム管理者はどのように対処すればよいのだろうか。本コラムで繰り返し述べているように，ベンダーからのパッチを入手し，適用するのが第一である。 しかし，すぐにパッチが提供されない場合があるし，提供されてもシステム環境によってはすぐに適用できない場合もあるだろう。そのような場合には，ぜい弱性があるプログラムに手を加えるのではなく，プログラムが実行されるプラットフォーム側でバッファ・オーバーフローの発生を抑制し，影響を最小限にする方法が望ましい。実際にそのような方法が存在するので，そのいくつかを紹介する。 いうまでもなく，プログラムはOS上で動作する。そこで，OSレベルでバッファ・オーバーフローを抑制することはできないだろうか。実は，Solaris 2.6以降のSPARC版では，カーネルのオプションを変更することで，バッファ・オーバーフローを利用する攻撃をある程度防ぐことができる。 上記の1行目でスタック上の実行権限を外し，2行目ではsyslogへログを出力する設定にしている。1行目の設定で，少なくともバッファ内のスタック領域をあふれさせる攻撃によるコードの実行を防げる。 カーネル・オプションの変更で対処できるOSおよびハードウエアは限られている。対処できないOSを使っている場合にはどうすればよいか。考えられる方法の一つが，プログラムが必ず利用するライブラリで対処する方法である。それも，libcのような基本的なライブラリに，バッファ・オーバーフローを抑制する機能を加えて対処するのである。実際，そのようなライブラリが公開されている。「libsafe」だ。 libsafeを使えば，C言語標準（ANSI-C）のライブラリに含まれる標準関数を呼び出す際に引き起こされるバッファ・オーバーフローを抑えられる。具体的には，libsafeはライブラリの呼び出し順序を変更し，バッファ・オーバーフローをチェックするコードを読み込ませた後に，本来呼び出されるライブラリの内容を呼び出す。 libsafeの最新版はlibsafe-2.0-16である。ソース・ファイルからインストールしてもよいが，RPMも用意されているので，Linuxユーザーはそちらを利用したほうが便利だろう。 libsafeを使用するには，各プログラムが既存の共有ライブラリよりもlibsafeを先に読み込むようにシステムの設定を変更する必要がある。ここでは環境変数 LD_PRELOADを使用して読み込み順序を変更する方法を紹介する。 ただし，リンカーが必ず読みに行くディレクトリにlibsafe.so.2 を配置する必要がある。多くの場合は /lib である。なお，libsafe をデフォルトのままインストールすると， /lib 以下にコピーされる。 次に，libsafeがバッファ・オーバーフローを抑止するかどうか，実際に試してみた。テストには，次のようなプログラムを使用した（プログラム名はインストール前で“test”，後で“test2”とする）。見てお分かりのように，実行すれば必ずバッファ・オーバフローするプログラムである。 インストール前には，プログラムがオーバーフローした後，Segmentation faultが発生している。もし今回のテスト・プログラムの入力値（long string）にコードが仕込まれていた場合には，そのコードはテスト・プログラムの実行権限で実行される恐れがある。 しかし，インストール後は，バッファ・オーバーフローが発生した時点でプログラムが終了している。つまり，プログラムが提供するサービスが停止することはあっても，バッファ・オーバーフローしたデータに含まれるコードが，そのまま実行されてしまうことはない。 OSやライブラリ以外に，コンパイラを変更することでバッファ・オーバーフローを抑制する方法もある。この場合には，プラットフォーム側でバッファ・オーバーフローを抑えるのではなく，それぞれのプログラムにバッファ・オーバーフローを検知する機能を追加する。そのようなコンパイラの一例が「StackGuard」である。 StackGuardはGNU C Compiler（gcc）の拡張版である。StackGuard付きでコンパイルされたプログラムは，実行時，リターン・アドレスの後に「カナリア」と呼ばれる確認用のコードを付加する。もし，関数が戻された際にこのコードが変更されていた場合にはバッファ・オーバーフローが発生したと判断し，プログラムを停止させるようになっている。なお，コンパイル時にオプションを付ければ，通常のgccとして使用できる。 同様のコンパイラとして，「StackShield」がある。こちらもgccの拡張版である。StackGuardとの違いは，確認用コード「カナリア」の保護方法である。対象プラットフォームはIntel386アーキテクチャのLinuxである。 以上のような方法で，バッファ・オーバーフローの発生をある程度防止できる。しかし，いずれもバッファ内のスタック領域のオーバーフローには対応できるものの，ヒープ領域のオーバーフローについては対応できない（詳細については割愛する）。 また，バッファ・オーバーフローを防ぐコードを挿入する方法では，プログラム実行時のパフォーマンスが低下する。さらに，スタック領域のオーバーフローに対しても，今回紹介した方法で100％防げるわけではない。パッチを適用する必要がなくなるわけでは決してない。あくまでも，パッチを適用するまでの急場しのぎの一つと考えていただきたい。 加えて，今回紹介したソフトウエアには，過去にセキュリティ・ホールが見つかっている。ソフトウエアである以上，仕方がないことではあるが，セキュリティ・ホール情報には注意したい。もちろんこのことは，今回紹介したソフトウエアに限った話ではない。 IT Proセキュリティ・サイトが提供する「今週のSecurity Check [一般編]」は，その週に起きたUNIX関連およびセキュリティ全般のニュースや動向をまとめた週刊コラムです。セキュリティ・ベンダーである「株式会社ラック」のスタッフの方を執筆陣に迎え，専門家の立場から解説していただきます。 ■Webアプリ防御ソフト---クッキーの書き換えなどを防止，カスタマイズが面倒な面も（上） (2002/08/27) ■「不正アクセスにはIDSよりスキャニングが効く」---米nCircle副社長に製品戦略を聞く (2002/04/30) 【IT Service Forum 2007】「シン・クライアントも一式丸ごとレンタルで」，JBサービスの古宇田社長 情報システム 業務アプリケーション 上流工程 SaaS＆Enterprise 2.0 グローバル・ソーシング ITpro協力誌 日経コンピュータ 日経コミュニケーション 日経SYSTEMS 日経情報ストラテジー 日経NETWORK 日経ソリューションビジネス 日経ソフトウエア 日経Linux 日経ニューメディア 日経BPガバメントテクノロジー 日経パソコン 日経BPソフトプレス IT経営 システム開発 プロマネ＆アーキテクト ネットワーク最新テクノロジー 業績＆業界動向 セキュリティ Windows オープンソース 製品＆サービス・ディレクトリ 業務アプリケーション 設計開発 OS/DB/ミドルウエア サーバー/ストレージ 運用管理 ネットワーク セキュリティ SIサービス 通信サービス クライアント/OA機器 |
[ 135] バッファ・オーバーフローの発生を抑える方法：ITpro
[引用サイト] http://itpro.nikkeibp.co.jp/members/ITPro/SEC_CHECK/20020920/1/
|
複数の機器やソフトウェアの間でデータをやり取りするときに、処理速度や転送速度の差を補うためにデータを一時的に保存しておく記憶装置や記憶領域のこと。 例えば、コンピュータがプリンタにデータを送る場合、プリンタが受信したデータを紙に印刷する速度は、コンピュータとプリンタの間の通信速度よりも遥かに遅い。何も考えずにプリンタに次々データを送ってしまうと、印刷が追いつかずに途切れ途切れに印刷されてしまう。このため、プリンタの内部には半導体メモリが内蔵されており、受信したデータを一時的に蓄えておき、印刷速度にあわせて順次データを読み出して印刷を行なうようにできている。 TCP/IPを実機で学べる！ネットワーク基礎講座ロボットカー制御プログラミング体験講座月収40万円以上のIT派遣のお仕事Excel VBA実践編 「VBAランクUP術」ネットワークエンジニアのお仕事一覧Ciscoルータ実機体験無料セミナー有名企業！技術系の仕事を検索大手・優良企業の技術者になる方法3DCAD エンジニア育成支援セミナー組込み技術習得までの道のり未経験からエンジニアへ全国47都道府県のエンジニアを募集中' ); Ethernetのしくみとハードウェア設計技法―プロトコル..絶対わかる!ネットワーク設計超入門―ネットワークのし..絶対わかる!インターネットのしくみ超入門 (日経BPムッ..絶対わかる!Windowsネット超入門 増補改訂版―ネットワ..絶対わかる!新・ネットワークセキュリティ超入門 増補..絶対わかる!ネットワークの基礎超入門―ネットワークの..図解入門 よくわかる最新IP‐VPNの基本と仕組み―仮想..絶対わかる!実践ネットワーク超入門―ネットワークのし..絶対わかる!TCP/IP超入門 増補改訂版―ネットワークの.. BURN-Proof ..-RやCD-RWの書き込み中に発生する「バッファアンダーランエラー」を、無視可能な程度にまで低減する。ディスクに書き.. GDDR ..表示および演算を行うために、VRAM中のバッファに高速でアクセスできる必要がある。さらにビデオカードはマザーボードの.. NINTENDO 64 ..担することにより、ハードウェアによるz-バッファやエッジアンチエイリアシング、テクスチャマッピングなどを実現し.. OpenGL ..)が行っている。テクスチャマッピングやZバッファ法、グローシェーディングなど多彩な機能を持ち、Windows NTにも標準.. XScale ..拡張やマルチメディア命令の追加、分岐予測バッファの搭載によってマルチメディア機能を強化している。また、高速化も.. XScaleマイクロアーキテクチャ ..拡張やマルチメディア命令の追加、分岐予測バッファの搭載によってマルチメディア機能を強化している。また.. Zバッファ法 ..で用いる奥行き情報のためのメモリ領域をZバッファと呼ぶ。この方法はアルゴリズムが単純なためハードウェア化しや.. 隠面消去 ..る面を描画しないようにする処理のこと。Zバッファ法、レイトレーシング法などいくつかの処理法がある。 陰面処理 ..る面を描画しないようにする処理のこと。Zバッファ法、レイトレーシング法などいくつかの処理法がある。 ステンシルバッファ ..を効率よく判定するために用意された特殊なバッファ領域。ポリゴンを描画する際にステンシルバッファを参照し、.. ディスプレイキャッシュ ..体の重ね合わせの判定のために用いられるZバッファという手法のために設けられたメモリで、i810では4MBのディ.. ニンテンドウ64 ..担することにより、ハードウェアによるz-バッファやエッジアンチエイリアシング、テクスチャマッピングなどを実現.. バッファアンダーラン ..中は他の作業を控えるように言われるのは、バッファアンダーランによるエラーを未然に防ぐためである。2000年に.. バッファオーバーフロー ..代表的なセキュリティホールの一つ。また、バッファオーバーフローを悪用して遠隔地からコンピュータを乗っ取.. バッファオーバーラン ..代表的なセキュリティホールの一つ。また、バッファオーバーフローを悪用して遠隔地からコンピュータを乗っ取る.. バーンプルーフ ..-RやCD-RWの書き込み中に発生する「バッファアンダーランエラー」を、無視可能な程度にまで低減する。ディスクに書.. ファイルディスクリプタ ..。OSによってはファイルディスクリプタにバッファ管理機能なども含めた「ファイルハンドル」と呼ばれる管理体.. 未確定文字列 ..字列である。未確定文字列は変換システムのバッファ内に一時的に保存されており、入力を行なっているアプリケーショ.. レジスタードDIMM レジスタードバッファ(registered buffer)と呼ばれるLSIを内蔵したメモリモジュール製品。これが組み込まれていない.. レジスタードメモリ レジスタードバッファ(registered buffer)と呼ばれるLSIを内蔵したメモリモジュール製品。これが組み込まれていな.. 関連用語は自動でリンクしているため、同音異義語など不適切なリンクが一部ございますがご容赦ください。' ); |
[ 136] バッファとは 【buffer】 - 意味・解説 ： IT用語辞典
[引用サイト] http://e-words.jp/w/E38390E38383E38395E382A1.html
