(Translated by https://www.hiragana.jp/)
バッファオーバーフロー - Wikipedia
Wikipedia

バッファオーバーフロー

バッファオーバーフロー（英えい: buffer overflow）またはバッファオーバーラン（英えい: buffer overrun）は、コンピュータのプログラムにおけるバグのひとつ、またはそれにより引ひき起おこされる現象げんしょうで、プログラムがバッファに割わり当あてられた空間くうかんよりも大おおきなデータを書かき込こむことで、データがバッファ境界きょうかいからあふれ、バッファの範囲はんい外がいのメモリを上書うわがきし、元々もともとそのメモリにあったデータを破壊はかいしてしまうことを指さす。

バッファオーバーフローは、上書うわがきされるメモリ領域りょういきがスタック領域りょういきなのかヒープ領域りょういきなのかに応おうじてそれぞれスタックベースのバッファオーバーフロー、ヒープベースのバッファオーバーフローと呼よばれる。なお、名称めいしょうが似にているスタックオーバーフローとは別べつの現象げんしょうである。

サイバーセキュリティ・情報じょうほうセキュリティの分野ぶんやでは、バッファオーバーフローはメモリ破壊はかい系けいの脆弱ぜいじゃく性せいの一ひとつとして知しられ[1]、攻撃こうげき者しゃがバッファオーバーフロー脆弱ぜいじゃく性せいのあるプログラムに意図いと的てきに悪意あくいのあるデータ（コード）を与あたえることにより、コンピュータの制御せいぎょを乗のっ取とってしまうことを可能かのうにする。バッファオーバーフロー脆弱ぜいじゃく性せいを悪用あくようした攻撃こうげきをバッファオーバーフロー攻撃こうげきという[2]。

バッファオーバーフローの具体ぐたい例れい

編集へんしゅう

簡単かんたんな例れい

編集へんしゅう

以下いかの例れいでは、プログラム中ちゅうの隣接りんせつしたアドレスに2つのデータ項目こうもくが定義ていぎされている。一ひとつは 8 バイトの文字もじ列れつバッファ A、もう一ひとつは 2 バイトの整数せいすう B である。初期しょき状態じょうたいでは、A は 0 で初期しょき化かされており可読かどくな文字もじは入はいっていない。また、B には整数せいすう 1,979 が格納かくのうされている。文字もじのバイト幅はばは 1 バイトとする。また、エンディアンはビッグエンディアンとする。

変数へんすう名めい A B
値ね NUL NUL NUL NUL NUL NUL NUL NUL 1979
16進しん数値すうち 00 00 00 00 00 00 00 00 07 BB

ここで、プログラムがバッファ A にヌル終端しゅうたん文字もじ列れつ「excessive」を書かきこもうとした場合ばあいを考かんがえる。文字もじ列れつの長ながさチェックが行おこなわれていないと、この処理しょりで B の値ねが上書うわがきされてしまう。

変数へんすう名めい A B
値ね 「e」 「x」 「c」 「e」 「s」 「s」 「i」 「v」 25856
16進しん数値すうち 65 78 63 65 73 73 69 76 65 00

プログラマとしては B を変更へんこうする意図いとはなかったが、B の値ねは文字もじ列れつの一部いちぶで置おき換かえられてしまった。この例れいではビッグエンディアンとASCIIコードを仮定かていしているため、文字もじ「e」とゼロというバイト列れつは整数せいすう 25,856 として解釈かいしゃくされる。ここで、仮かりにプログラム中ちゅうで A と B 以外いがいにデータ項目こうもく変数へんすうが定義ていぎされていないとものすると、さらに長ながい文字もじ列れつを書かき込こんで B の終端しゅうたんを超こえた場合ばあいにはセグメンテーション違反いはんなどのエラーが発生はっせいしてプロセスが終了しゅうりょうする。

電子でんしメールアドレスを題材だいざいにした例れい

編集へんしゅう

コンピュータプログラムを作つくるとき、固定こてい長ちょうのバッファとよばれる領域りょういきを確保かくほしてそこにデータを保存ほぞんするという手法しゅほうがよく使つかわれる。

たとえば、電子でんしメールアドレスは200文字もじを超こえないだろうと予想よそうして

  1. 200文字もじ分ぶんの領域りょういきをバッファとして用意よういする。
  2. ユーザが200文字もじより長ながいメールアドレスを入力にゅうりょくする。
  3. プログラムがバッファの大おおきさをチェックせずに入力にゅうりょくデータを書かき込こむ。
  4. バッファとして確保かくほした領域りょういきをはみだしてデータが書かき込こまれてしまう。

これがバッファオーバーフローである。仮かりにはみ出だした部分ぶぶんにプログラムの動作どうさ上じょう意味いみを持もつデータがあれば、これを上書うわがきして破壊はかいすることにより、プログラムはユーザの意図いとしない挙動きょどうを示しめすであろう。

このようにバッファオーバーフローは、プログラムが用意よういしたバッファの大おおきさを超こえてデータを書かき込こんでしまうバグである。

C言語げんご特有とくゆうの例れい

編集へんしゅう

C言語げんごの標準ひょうじゅん入出力にゅうしゅつりょく関数かんすうであるgets関数かんすうはバッファ長ちょうのチェックを行おこなわないで標準ひょうじゅん入力にゅうりょくをバッファに書かき込こむので、この関数かんすうを使つかう全すべてのプログラムには、バッファオーバーフローによる不正ふせい動作どうさの危険きけん性せいがある。また使つかい方かたが分わかりやすいという理由りゆうでC言語げんご初心者しょしんしゃ向むけの入門にゅうもんプログラミングでしばしば用もちいられるscanf関数かんすうも書式しょしき指定していを誤あやまった場合ばあいは同おなじ危険きけん性せいを持もっている[3]。これらの関数かんすうを実用じつよう的てきなプログラムで用もちいる場合ばあいには注意ちゅういが必要ひつようである。

次つぎのプログラムはgets関数かんすうを用もちいた例れいである（セキュリティ上じょう、gets関数かんすうはそれ自体じたいをテストする以外いがいの目的もくてきで使用しようされるべきではない。Linux Programmer's Manualには「gets()は絶対ぜったいに使用しようしてはならない」と書かかれている）。バッファ長ちょうとして200バイト確保かくほされている。gets関数かんすうはバッファの長ながさについては関知かんちしないため、200バイトを超こえても改行かいぎょう文字もじかEOFが現あらわれなければバッファオーバーフローが発生はっせいする。 

#include <stdio.h>
int main(int argc, char *argv[])
{
  char buf[200];
  gets(buf);
  ....
}

gets関数かんすうの代かわりにfgets関数かんすうを用もちいることで、この問題もんだいを回避かいひできる（fgets#getsを置おき換かえる例れい等ひとしを参照さんしょう）。fgets関数かんすうにはバッファのサイズを渡わたすことができ、このバイト数すうを超こえてバッファに書かき込こみを行おこなわない。したがってバッファサイズが正ただしく設定せっていされていれば、fgets関数かんすうにおいてバッファオーバーフローは起おこり得えない。

これ以外いがいのC言語げんごの標準ひょうじゅん文字もじ列れつ処理しょり関数かんすうの多おおくにも同様どうようの問題もんだい（脆弱ぜいじゃく性せい）がある。

バッファオーバーフロー攻撃こうげき

編集へんしゅう

情報じょうほうセキュリティ・サイバーセキュリティにおいてバッファオーバーフロー攻撃こうげきは、バッファオーバーフローの脆弱ぜいじゃく性せいを利用りようした攻撃こうげきである。バッファオーバーフローの脆弱ぜいじゃく性せいは整数せいすうオーバーフロー、書式しょしき文字もじ列れつバグ、Use-After-Freeなどと同様どうよう、メモリ破壊はかい系けいの脆弱ぜいじゃく性せいに相当そうとうする[1]。

共通きょうつう脆弱ぜいじゃく性せいタイプCWEには、

番号ばんごう 名称めいしょう
CWE-120 入力にゅうりょくサイズをチェックしないバッファのコピー（古典こてん的てきバッファオーバーフロー）[4]
CWE-121 スタックベースのバッファオーバーフロー[5]
CWE-122 ヒープベースのバッファオーバーフロー[6]

などが登録とうろくされており、これら3つはいずれも「CWE-119: メモリバッファの境界きょうかい内ないにおける操作そうさの不適切ふてきせつな制限せいげん」[7]に属ぞくしている[7][8]。

これら3つのバッファオーバーフロー脆弱ぜいじゃく性せいが頻繁ひんぱんに生しょうじるのはC言語げんごやC++であり[4][5][6]、古典こてん的てきバッファオーバーフローはアセンブリ言語げんごでも生しょうじる[4]。

これら3種類しゅるいのバッファオーバーフローはセキュリティポリシーの外側そとがわで任意にんいのコードを攻撃こうげき者しゃに実行じっこう可能かのうにする事ことが頻繁ひんぱんにある[4][5][6]。さらに任意にんいのコードの実行じっこうにより他たのセキュリティサービス機構きこうを破壊はかいする事ことも可能かのうになる[4][5][6]。またこれら3種類しゅるいのバッファオーバーフローはクラッシュの原因げんいんにもなるので[4][5][6]、意図いと的てきにクラッシュさせる攻撃こうげきが可能かのうになる[4][5][6]。

CWEでは「CWE-193: Off-by-oneエラー」[9]がバッファオーバーフローの原因げんいんになると述のべられており[10]、整数せいすうオーバーフローもバッファオーバーフローの原因げんいんになる事ことが述のべられている[11]。

古典こてん的てきバッファオーバーフロー攻撃こうげき

編集へんしゅう

バッファAの値ねを他たのバッファBにコピーするとき、BのバッファサイズがAのバッファサイズよりも大おおきいことをチェックしない場合ばあいに生しょうじる脆弱ぜいじゃく性せいである[4]。この脆弱ぜいじゃく性せいは、プログラマーがこのようなチェックの実装じっそうを怠おこたった事ことにより生しょうじる[4]。これはプログラマーが最低限さいていげんのセキュリティチェックすらしていないことを強つよく示唆しさする[4]。

脆弱ぜいじゃく性せいの具体ぐたい例れいとしては、例たとえばC言語げんごやC++において、配列はいれつサイズをチェックする事ことなく、配列はいれつにstrcpyやscanfで文字もじ列れつ等とうをコピーするといったものがある[4]。攻撃こうげき者しゃは意図いと的てきに大おおきな入力にゅうりょくをstrcpy、scanf、getsに与あたえることで、古典こてん的てきバッファオーバーフローを不正ふせいに生しょうじさせる事ことができる[4]。

例たとえば攻撃こうげき者しゃがバッファAをバッファオーバーフローさせる事ことにより、Aの隣となりにある変数へんすうxを不正ふせいに変更へんこうできた場合ばあい、xがセキュリティ上じょう重要じゅうようなデータ（例たとえば管理かんり者しゃ権限けんげんを持もっているか否ひかを判定はんていするビットを保持ほじしている）であれば、セキュリティ上じょう重要じゅうような問題もんだいが生しょうじる。

スタックベースのバッファオーバーフロー攻撃こうげき

編集へんしゅう

スタックベースのバッファオーバーフローは「上書うわがきされるバッファがスタック（すなわち、局所きょくしょ変数へんすうや、まれに関数かんすうのパラメータ）にアロケートされる」[5]事ことが可能かのうな場合ばあいに生しょうじる脆弱ぜいじゃく性せいである。このような脆弱ぜいじゃく性せいはファジングを使用しようして発見はっけんされることが多おおい[12]。

C言語げんご・C++におけるメモリ領域りょういき

編集へんしゅう

スタックベースのバッファオーバーフローについて説明せつめいするためにプロセスのメモリ利用りよう方法ほうほうを復習ふくしゅうする。オペレーティングシステム (OS) は各かくユーザプロセスに仮想かそうアドレス空間くうかんを割わり振ふり、WindowsやLinuxなどのOSでは上位じょういのアドレスをカーネルが使つかうカーネル空間くうかんとし、残のこりをユーザプロセス自身じしんが用もちいるユーザ空間くうかんとする[注釈ちゅうしゃく 1]。カーネル空間くうかんはユーザプロセスがアクセスする事ことはできず、通常つうじょうのプログラミングでは意識いしきする事ことはない。

C言語げんごやC++で書かかれたプログラムの場合ばあい、ユーザ空間くうかんをさらに分割ぶんかつする。これらの言語げんごで書かかれたプログラムでは、仮想かそうアドレスの最低さいてい位いの箇所かしょから順じゅんにプログラムの実行じっこうコードを置おくコード領域りょういき（テキスト領域りょういきとも）、初期しょき化かされた静的せいてき変数へんすう・大域たいいき変数へんすうを置おくデータ領域りょういき、初期しょき化かされていない静的せいてき変数へんすう・大域たいいき変数へんすうを置おくbss領域りょういき[注釈ちゅうしゃく 2][注釈ちゅうしゃく 3]、malloc等とうで動的どうてきに確保かくほされたメモリを置おく（可変かへんサイズの）ヒープ領域りょういきを確保かくほする[13]。

一方いっぽう、ユーザ空間くうかんにおける仮想かそうアドレスの最高さいこう位いの箇所かしょは関数かんすうのコールスタックを保存ほぞんする（可変かへんサイズの）スタック領域りょういきとして用もちいられる[13]。

最低さいてい位い … 最高さいこう位い
コード領域りょういき 静的せいてき領域りょういき ヒープ領域りょういき

（高位こういに向むかって成長せいちょう→）

… スタック領域りょういき

（←低位ていいに向むかって成長せいちょう）

データ領域りょういき bss領域りょういき

スタック領域りょういきはプロセス中ちゅうで呼よばれる関数かんすうのコールスタックを格納かくのうする領域りょういきで、コールスタック中ちゅうの各かく関数かんすうのデータ（スタックフレームという）を並ならべて格納かくのうしている[14]。プロセス中ちゅうで関数かんすうfが関数かんすうgを呼よび出だした場合ばあい、コールスタックは以下いかのようになる[14][15]：

低位ていいアドレス … 高位こういアドレス
… gのスタックフレーム fのスタックフレーム …
… gの処理しょりに必要ひつような一時いちじ的てきな情報じょうほう gの局所きょくしょ変数へんすう gのSFP gのリターンアドレス gの引数ひきすうの値ね fの処理しょりに必要ひつような一時いちじ的てきな情報じょうほう … …

プロセスで現在げんざい実行じっこう中ちゅうの関数かんすうのスタックフレームの位置いちを覚おぼえるためにプロセッサによって用もちいられるのがフレームポインタ[注釈ちゅうしゃく 4]で、具体ぐたい的てきには（現在げんざい実行じっこう中ちゅうの関数かんすうがgであれば）gのSFPのアドレスを指さしている。SFPは関数かんすう呼よび出だし時じに呼よび出だし元もとの関数かんすうのフレームポインタのアドレスを覚おぼえるための領域りょういきで、fがgを呼よび出だした際さい、スタックフレームの値ね（＝fのSFPのアドレス）をgのSFPに格納かくのうする。なお、SFPは「Saved Frame Pointer」の略りゃくで、日本語にほんご訳やくは「退避たいひされたフレームポインタ」である[14]。

一方いっぽうgのリターンアドレスは呼よび出だし元もと関数かんすうfのプログラムカウンタ[注釈ちゅうしゃく 5]のアドレスを格納かくのうする[14]。

攻撃こうげきの基本きほん的てきアイデア

編集へんしゅう

今いま例たとえば、関数かんすうgはユーザから（ASCIIコードの）文字もじ列れつを入力にゅうりょくを受うけ取とり、入力にゅうりょくされた文字もじ列れつを配列はいれつchar A[10]に格納かくのうするとする。Aのサイズは10であるので、関数かんすうgのプログラマはユーザから受うけ取とった文字もじ列れつをAに格納かくのうする前まえに、その文字もじ列れつが本当ほんとうに10文字もじ以下いかなのかをチェックする機構きこうをgに実装じっそうしておかねばならない。このようなチェック機構きこうを実装じっそうするのを忘わすれていた場合ばあい、悪意あくいのあるユーザ（以下いか、「攻撃こうげき者しゃ」と呼よぶ）によりスタックベースのバッファオーバーフロー攻撃こうげきを受うけてしまう危険きけんがある。

具体ぐたい的てきには、攻撃こうげき者しゃは以下いかのような文字もじ列れつをgに入力にゅうりょくする：

（シェルコード）…（シェルコードの仮想かそうアドレス）

ここでシェルコードとは、何なんらかの悪意あくいのある短みじかいプログラムで、例たとえば攻撃こうげき者しゃのためにバックドアを開あけたり、マルウェアのダウンロードを行おこなったりする[15]。

この文字もじ列れつが配列はいれつAの先頭せんとうから順じゅんに書かき込こまれていくと、A[i]のアドレスはiが大おおきいほど大おおきくなるので、攻撃こうげき者しゃが入力にゅうりょく文字もじ列れつの長ながさを適切てきせつに選えらべば、アドレス空間くうかんには以下いかのようにデータが書かき込こまれ、gのリターンアドレスがシェルコードの仮想かそうアドレスに上書うわがきされる[15]：

低位ていいアドレス … 高位こういアドレス
… gのスタックフレーム fのスタックフレーム …
… gの処理しょりに必要ひつような一時いちじ的てきな情報じょうほう gの局所きょくしょ変数へんすう gのSFP gのリターンアドレス gの引数ひきすうの値ね fの処理しょりに必要ひつような一時いちじ的てきな情報じょうほう … …
(シェルコード)… … （シェルコードの仮想かそうアドレス）

よって関数かんすうgが終了しゅうりょうしたとき、gのリターンアドレス（の箇所かしょに上書うわがきされたシェルコードの仮想かそうアドレス）が読よみ込こまれるので、プログラムカウンタはシェルコードの位置いちにジャンプし、攻撃こうげき者しゃの狙ねらい通どおり、シェルコードが実行じっこうされる事ことになる[15]。

NOPスレッド

編集へんしゅう

上うえで述のべた攻撃こうげきのアイデアが実行じっこう可能かのうであるためには、攻撃こうげき者しゃがリターンアドレスに上書うわがきすべき仮想かそうアドレスを正確せいかくに知しり、それを関数かんすうgに入力にゅうりょくする必要ひつようがあるが、スタックは動的どうてきに変化へんかするため、これは容易よういではない[16]。そこで本節ほんぶしではリターンアドレスに上書うわがきすべき仮想かそうアドレスの「おおよその値ね」さえ分わかれば攻撃こうげきが可能かのうになるテクニック（NOPスレッド）を述のべる。

NOPとは「何なにも行おこなわない」事ことを意味いみするアセンブリ命令めいれいで[16]、本来ほんらいはタイミングを合あわせるなどの動機どうきにより何なにもせずにCPU時間じかんを消費しょうひするために用もちいられる[16]。NOPスレッド(sled、そり)[16]とはこのNOP命令めいれいを複数個ふくすうこ並ならべたもので、これを利用りようする事ことにより攻撃こうげき対象たいしょうの関数かんすうをシェルコードの位置いちまで滑走かっそうさせる。

具体ぐたい的てきには攻撃こうげき者しゃは下記かきのような文字もじ列れつを攻撃こうげき対象たいしょうの関数かんすうgに入力にゅうりょくする：

NOP … NOP (シェルコード)(戻もどりアドレス)…(戻もどりアドレス)

最初さいしょの「NOP … NOP」の部分ぶぶんがNOPスレッドである。攻撃こうげき者しゃがNOPスレッドの長ながさや戻もどりアドレスの繰くり返かえし回数かいすうを適切てきせつに選えらんでgに入力にゅうりょくすると、スタック領域りょういきは例たとえば以下いかのようになる（攻撃こうげきに関係かんけいする部分ぶぶんだけ抜書ぬきがき）：

gのスタックフレーム fのスタックフレーム
… gの局所きょくしょ変数へんすう gのSFP gのリターンアドレス …
… NOP… NOP … NOP …NOP (シェルコード)…(戻もどりアドレス)…(戻もどりアドレス) (戻もどりアドレス) (戻もどりアドレス)…

これでgのリターンアドレスは「戻もどりアドレス」にセットされるので、攻撃こうげき者しゃが「戻もどりアドレス」としてNOPスレッド部分ぶぶんのアドレスを指定していする事ことに事前じぜんに成功せいこうしていれば、gの終了しゅうりょう時じにNOPスレッドへとプログラムカウンタが移動いどうする。するとプログラムはNOPを順じゅんに実行じっこうして右みぎへ右みぎへと移動いどうし、シェルコードの位置いちにたどり着ついてシェルコードが実行じっこうされるので、攻撃こうげき成功せいこうとなる[16][17]。戻もどりアドレスがNOPスレッドのどこかに落おちさえすればよいので、前節ぜんせつで述のべた攻撃こうげき違ちがい、リターンアドレスにセットする値ねを完璧かんぺきに制御せいぎょする必要ひつようはなく、NOPスレッドの長ながさ分ぶんの誤差ごさが発生はっせいしても攻撃こうげきが成功せいこうする事ことになる。

NOPスレッドは頻繁ひんぱんに使用しようされるため、多おおくの侵入しんにゅう防止ぼうしシステムベンダーでシェルコードの判定はんていに使用しようされている。このため、エクスプロイトの作成さくせい者しゃ側がわでは、シェルコードの実行じっこうに影響えいきょうを及およぼさない（NOP以外いがいの）任意にんいの命令めいれいをランダムに選えらんでスレッドを構成こうせいすることが常套じょうとう手段しゅだんとなっている[18]。

戻もどりアドレスの値ねの予想よそう

編集へんしゅう

攻撃こうげきを実行じっこうするには、あとは「戻もどりアドレス」として具体ぐたい的てきにどの程度ていどの値ねを代入だいにゅうすればよいかを知しればよい。しかし攻撃こうげきの標的ひょうてきとなる組織そしきの環境かんきょうで戻もどりアドレスの絶対ぜったいアドレスがいくつ程度ていどの値ねになるのかを事前じぜんに知しる事ことは難むずかしい。そこで相対そうたいアドレスを利用りようして戻もどりアドレスを適切てきせつに選えらぶ攻撃こうげきテクニックを紹介しょうかいする。この攻撃こうげきのシナリオでは、攻撃こうげき者しゃはシェルコードを含ふくんだ攻撃こうげき用ようのプログラムh（をコンパイルして作つくった実行じっこうコード）を攻撃こうげきの標的ひょうてきとなる組織そしきに送おくりつけ、hのサブルーチンとしてgを呼よび出だす事ことで攻撃こうげきを行おこなう。

この攻撃こうげき用ようプログラムhでは、変数へんすうxを宣言せんげんが宣言せんげんされているものとする。hが標的ひょうてきの環境かんきょうでgを呼よび出だしたとき、gのスタックフレームはスタック領域りょういき上じょうでhのスタックフレームのすぐ隣となりに配置はいちされる事ことから、攻撃こうげき用よう文字もじ列れつを入いれ込こむgの変数へんすうの絶対ぜったいアドレスvar_addは

var_add = &x - (小ちいさな値ね)

になるはずである[16]。ここで「&x」はxのアドレスを表あらわす。既すでに述のべたようにNOPスレッドを使つかった攻撃こうげきでは戻もどりアドレスとしてvar_add近辺きんぺんの値ねを選えらべば成功せいこうするので、攻撃こうげき者しゃはこの「小ちいさな値ね」を決定けっていしさえすればよい。

よって攻撃こうげき者しゃは関数かんすうgの実行じっこうコードを事前じぜんに入手にゅうしゅし、(シェルスクリプト等ひとしを使つかって)NOPスレッドの長ながさや戻もどりアドレスを変かえながら攻撃こうげき対象たいしょうのプログラムを何なん度ども実行じっこうすることで適切てきせつな「小ちいさな値ね」を選えらび、その「小ちいさな値ね」を攻撃こうげき用ようプログラムhに書かき込こんでおけばよい[16]。

埋うめ込こめるコード量りょうが小ちいさい場合ばあいの対処たいしょ

編集へんしゅう

関数かんすうgに埋うめ込こむ攻撃こうげき用ようの文字もじ列れつは「NOPスレッド+シェルコード+戻もどりアドレスの繰くり返かえし」という形かたちをしており、gのリターンアドレスが「戻もどりアドレスの繰くり返かえし」の部分ぶぶんに落おちない限かぎり攻撃こうげきは成功せいこうしないので、関数かんすうgに攻撃こうげき用よう文字もじ列れつを埋うめ込こむ箇所かしょとgのリターンアドレスとが（仮想かそうアドレス空間くうかん上じょうで）あまりに近ちかい場合ばあいは、攻撃こうげきに必要ひつような長ながさのシェルコードを埋うめ込こめないという問題もんだいが攻撃こうげき者しゃに生しょうじる。

しかし攻撃こうげき者しゃが攻撃こうげきの標的ひょうてきとなるマシンの環境かんきょう変数へんすうを設定せっていできる状況じょうきょう下かでは、攻撃こうげき者しゃはこの問題もんだいを回避かいひした攻撃こうげきが可能かのうである。標的ひょうてきマシンでプロセスが実行じっこうされる際さいには、そのプロセスの仮想かそうアドレス空間くうかんに環境かんきょう変数へんすうが読よみ込こまれるので、攻撃こうげき者しゃが事前じぜんに標的ひょうてきマシンの環境かんきょう変数へんすうに「NOPスレッド+シェルコード」を書かき込こんでおけば、プロセスの仮想かそうアドレスに「NOPスレッド+シェルコード」ができあがる事ことになる。プロセス中ちゅうで関数かんすうgが実行じっこうされた際さい、攻撃こうげき者しゃは攻撃こうげき用よう文字もじ列れつをgに入力にゅうりょくして、リターンアドレスをそのNOPスレッドに書かき換かえれば攻撃こうげきが成功せいこうする事ことになる[19]。

より確実かくじつな攻撃こうげき方法ほうほうとして、攻撃こうげきプログラムhの中なかに環境かんきょう変数へんすうを読よみ込こむ関数かんすう（getenv()等とう）を用もちいるものもある[20]。

ヒープスプレー

編集へんしゅう
詳細しょうさいは「ヒープスプレー（英語えいご版ばん）」を参照さんしょう

NOPスレッドを長ながくしすぎると、gのリターンアドレスの位置いちにすらNOPが書かき込こまれてしまって攻撃こうげきに失敗しっぱいする為ため、NOPスレッドを長ながくして攻撃こうげき成功せいこう率りつを上あげる手法しゅほうには限界げんかいがある。しかし攻撃こうげき者しゃがプロセスのヒープ領域りょういきの値ねをも自由じゆうに操あやつれるという条件下じょうけんかでは、攻撃こうげき者しゃはヒープスプレーというテクニックを用もちいる事ことにより、この限界げんかいを突破とっぱした攻撃こうげきを行おこなう事ことが可能かのうになる[21]。

ヒープスプレーでは、NOPスレッドとシェルコードを、スレッド領域りょういきではなくヒープ領域りょういきに埋うめ込こみ、戻もどりアドレスとしてヒープ領域りょういき中ちゅうのNOPスレッドを指定していする。ヒープ領域りょういき上じょうのNOPスレッドにはスレッド領域りょういきのNOPスレッドと違ちがい前述ぜんじゅつした長ながさの上限じょうげんが存在そんざいしないため、「長ながいNOPスレッド＋シェルコード」の組くみ合あわせを大量たいりょうにヒープ中ちゅうに書かき込こむことで攻撃こうげき成功せいこう率りつを上あげる[21]。

ウェブブラウザではJavaScriptなどのクライアントサイドスクリプトにより任意にんいの長ながさのヒープを作成さくせいできるので、ブラウザを対象たいしょうにしたドライブバイダウンロード攻撃こうげきではヒープスプレーが使つかわれる事ことが多おおい[21]。

トランポリング

編集へんしゅう

攻撃こうげき者しゃの入力にゅうりょくしたデータ（エクスプロイトなど）のアドレスは未知みちであるが、そのデータのアドレスがレジスタに格納かくのうされていることは分わかっているという場合ばあいには、トランポリン(trampolining)と呼よばれる手法しゅほうが利用りようされる。この手法しゅほうでは、攻撃こうげき者しゃの入力にゅうりょくしたデータにジャンプするオペコードのアドレスをリターンアドレスへ上書うわがきする。例たとえばアドレスがレジスタRに格納かくのうされている場合ばあい、jump R（あるいはcall Rなど）というオペコードが格納かくのうされているアドレスにジャンプさせることでユーザの入力にゅうりょくしたデータを実行じっこうさせる。この手法しゅほうで使用しようするオペコードはDLLや実行じっこうファイルの中なかのものを利用りようする。ただし、一般いっぱん的てきにオペコードのアドレスにヌル文字もじが含ふくまれていてはならず、また処理しょりに使用しようするオペコードのアドレスはアプリケーションやオペレーティングシステムのバージョンによって異ことなる。Metasploitプロジェクトはこのような目的もくてきに適てきしたオペコードのデータベースの一ひとつであり、Windowsで使用しようできるオペコードが記載きさいされている[22]。

ヒープベースのバッファオーバーフロー

編集へんしゅう

mallocなどでヒープ領域りょういきに動的どうてきにメモリを確保かくほする関数かんすうに対たいするオーバーフロー攻撃こうげきである[6]。基本きほん的てきな攻撃こうげき手法しゅほうとしては、関数かんすうがヒープに確保かくほしたメモリ領域りょういきが2つあるとき、そのうち一方いっぽうの領域りょういきに対たいして確保かくほ済ずみのメモリサイズより大おおきなデータを入力にゅうりょくする事ことでオーバーフローを起おこし、もう一方いっぽうのメモリ領域りょういきを書かき換かえるというものである[23]。mallocは複雑ふくざつな方法ほうほうでメモリ確保かくほの場所ばしょを決定けっていしているものの、連続れんぞくして2度どmallocを実行じっこうした場合ばあい、その結果けっかとして確保かくほされる2つのメモリ領域りょういきは（仮想かそうアドレス空間くうかん上じょうで）近ちかくに配置はいちされている傾向けいこうがあるため、上述じょうじゅつのようなバッファオーバーフロー攻撃こうげきが可能かのうになる。

mallocのメモリ管理かんり

編集へんしゅう

より高度こうどなヒープベースバッファオーバーフロー攻撃こうげき手法しゅほうを説明せつめいする為ための準備じゅんびとして、mallocのメモリ管理かんり方法ほうほうを説明せつめいする。なおメモリ管理かんり方法ほうほうの詳細しょうさいはmallocの実装じっそうに依存いぞんするため、実行じっこう環境かんきょうによって細こまかなところは下記かきの説明せつめいと異ことなる部分ぶぶんがあるので注意ちゅういされたい。

mallocは未み使用しようなヒープ領域りょういき（の一部いちぶ）をメモリプールとして管理かんりしており、メモリプールは複数ふくすうのchunkと呼よばれる単位たんいからなっている[24]。プログラム中ちゅうでmallocが実行じっこうされるたびに、管理かんりしているchunkの中なかから適切てきせつなサイズのものをプログラムに返かえす[24]。適切てきせつなサイズのchunkがない場合ばあいは、システムコールにより新あらたなchunkを確保かくほしてプログラムに返かえす[24]。mallocはchunkを（サイズ毎ごとに異ことなる複数ふくすうの[25]）連結れんけつリストとして管理かんりしており[24]、chunkをプログラムに渡わたす際さいにこの連結れんけつリストからchunkを削除さくじょし、プログラムがメモリ領域りょういきをfreeすると、freeされたchunkが連結れんけつリストに加くわわる[24]。

chunkは連結れんけつリストとして管理かんりされているので、各かくchunkには「次つぎのchunk」を指定していするポインタ（Windowsでは「flink」[26]、linuxでは「fd」[24]）や「前まえのchunk」を指定していするポインタ（Windowsでは「blink」[26]、linuxでは「bk」[24]）がある。

未み使用しようchunkと隣接りんせつするメモリ領域りょういきが解放かいほうされた場合ばあいは、解放かいほうされたメモリ領域りょういきと未み使用しようchunkとを連結れんけつ (coalesce) する事ことで1つの大おおきなchunkを作つくって管理かんりする[26]。

mallocのメタデータの書かき換かえ

編集へんしゅう

より高度こうどなヒープベースバッファオーバーフロー攻撃こうげきとして、mallocがメモリ管理かんりに使つかうメタデータを書かき換かえる手法しゅほうがある。例たとえばWindows XP SP1またはそれ以前いぜんのWindowsでは、mallocしたメモリ領域りょういきをオーバーフローさせる事ことで、そのメモリ領域りょういきの（仮想かそうアドレス空間くうかんで）隣となりにある未み使用しようchunkのflinkやblinkを任意にんいのアドレスに書かき換かえるという攻撃こうげき手法しゅほうが可能かのうであった[27]。flinkやblinkはcoalesceのタイミングでmallocにより参照さんしょうされるので攻撃こうげきが成功せいこうする[27]。

バッファオーバーフローの結果けっか

編集へんしゅう

write-what-where状態じょうたい

編集へんしゅう

バッファオーバーフロー攻撃こうげきの結果けっかとして、write-what-where状態じょうたい（"write-what-where condition"[28]、CWE-123[28]。任意にんいの場所ばしょに任意にんいの値ねを書かき込こむことができる状態じょうたい[29]）になる危険きけんがある[28]。

write-what-where状態じょうたいになると、セキュリティポリシーのスコープ外がいにメモリのデータを書かき込こむことができる[28]。セキュリティポリシーのスコープ外がいにコードを置おくことで、攻撃こうげき者しゃはほぼ確実かくじつに任意にんいのコードを実行じっこうできるようになる[28]。管理かんり者しゃ権限けんげんを制御せいぎょしているフラグ等とうが書かき換かえられる場合ばあいも、攻撃こうげき者しゃは任意にんいのコードが実行じっこう可能かのうになる[28]。

プログラムのフリーズ・クラッシュ

編集へんしゅう

攻撃こうげき者しゃは意図いと的てきにバッファオーバーフローを起おこすによりプログラムをクラッシュさせたり[4][5][6]、処理しょりを書かき換かえて無限むげんループに追おい込こむことでプログラムをフリーズさせてたり[4][5][6]する事ことでプログラムの可用性かようせいを侵害しんがいできる。

関数かんすうポインタの書かき換かえ

編集へんしゅう

古典こてん的てきバッファオーバーフロー[30]やヒープオーバーフロー[6]などの結果けっかとして、関数かんすうポインタの書かき換かえが可能かのうになるケースがある。攻撃こうげき者しゃはnmコマンドを用もちいる事ことでプログラム中ちゅうで用もちいられている様々さまざまな関数かんすうのアドレスを知しる事ことができるので[30]、nmの結果けっかを参照さんしょうして攻撃こうげきに利用りよう可能かのうな関数かんすうに関数かんすうポインタの値ねを書かき換かえられる。

技術ぎじゅつ的てき対策たいさく

編集へんしゅう

コンパイラやライブラリによる対策たいさく

編集へんしゅう

カナリア

編集へんしゅう

バッファオーバーフローを検出けんしゅつするコードをコンパイル時じに実行じっこうコードに挿入そうにゅうする手法しゅほうがある。典型てんけい的てき手法しゅほうとしては、ローカル変数へんすうとSFPの間あいだに、カナリア（canary）[31][32]もしくはクッキー[33]と呼よばれる領域りょういきを挿入そうにゅうする方法ほうほうである。プログラムは実行じっこう中ちゅうカナリアを監視かんしし続つづけ、バッファオーバーフローによりカナリアが書かき換かわったらプログラムを停止ていしする。

安全あんぜんなライブラリへの置おき換かえ

編集へんしゅう

標準ひょうじゅんCライブラリ等とうにはバッファオーバーフロー検知けんち機能きのうが施ほどこされていない関数かんすうが収録しゅうろくされているので、これを検知けんち機能きのうを持もった関数かんすうに置おき換かえたライブラリを標準ひょうじゅんCライブラリの代かわりに使つかう事ことで攻撃こうげきを検知けんちできる。例たとえばLibsafe[36]は標準ひょうじゅんCライブラリのstrcpy(*dest,*src)をより安全あんぜんな関数かんすうに置おき換かえており、入力にゅうりょくsrcのサイズがコピー先さきのdestのサイズが大おおきいか否ひかを検知けんちできる[37]。

実行じっこう環境かんきょうでの対策たいさく

編集へんしゅう

Write XOR eXecute

編集へんしゅう

典型てんけい的てきなスタックベースのバッファオーバーフロー攻撃こうげきでは、本来ほんらいデータを格納かくのうすべき領域りょういきにシェルコードやNOP命令めいれいのような実行じっこうコードを置おき、これをプログラムに実行じっこうさせる事ことで攻撃こうげきが成立せいりつする。そこでこのような攻撃こうげきを防ふせぐため、データを格納かくのうすべき領域りょういきでは実行じっこう不可ふかにする、Write XOR eXecute[37]（W X[37]もしくはW^Xと略りゃくす）という対策たいさく手法しゅほうが知しられている[37]。W XのWindowsにおける実装じっそうはDEP（英えい: data execution prevention、データ実行じっこう防止ぼうし）と呼よばれる[37][38]。またDEPではSEH例外れいがいハンドラへのポインタが上書うわがきされないように明示めいじ的てきに保護ほごを行おこなう[39]。 一部いちぶのUNIX（OpenBSDやmacOSなど）はW Xなどの実行じっこう保護ほごが有効ゆうこうになった状態じょうたいで出荷しゅっかされている。それ以外いがいのオプショナルなパッケージとしては以下いかのものが挙あげられる。

また、プロプライエタリなアドオンとしては以下いかのものがある。

なお、2018年ねん現在げんざい広ひろく使つかわれているx64アーキテクチャのプロセッサでは、W Xを実現じつげんする為ためにデータ領域りょういきである事ことを識別しきべつするNXビットという仕組しくみがハードウェアレベルでサポートされている[45]（インテルではNXビットのことをXDビットと呼よんでいるが同一どういつのものである[45]）。

ASLR

編集へんしゅう

バッファオーバーフロー攻撃こうげきを含ふくめたメモリ破壊はかい攻撃こうげき全般ぜんぱんを緩和かんわする技術ぎじゅつとしてASLR（Address Space Layout Randomization、アドレス空間くうかん配置はいちのランダム化か）がある。これは仮想かそうメモリ空間くうかんにおけるスタック領域りょういきやコード領域りょういきの位置いち、読よみ込こまれるDLLの位置いち等とうを（プログラム起動きどう時じもしくはOS自身じしんの起動きどう時じに）ランダムに変かえる技術ぎじゅつで、これにより攻撃こうげき者しゃが攻撃こうげきに有効ゆうこうな実行じっこうコードの特定とくてい箇所かしょを指定していしてメモリ改かいざんを行おこなうのを困難こんなんにする。

ASLRはバッファオーバーフロー攻撃こうげきの発展形はってんけいであるReturn-to-libc攻撃こうげき（後述こうじゅつ）を緩和かんわできるが、さらにその発展形はってんけいであるReturn-oriented programmingには対抗たいこうできない。

カーネル空間くうかんのASLRをKASLR（kernel address space layout randomization）といい、linuxカーネル(バージョン3.14以降いこう)[46]、iOS(バージョン6以降いこう)[47]などで実装じっそうされている。またKASLRをバイパスしようとする攻撃こうげきに対抗たいこうする為ための機構きこうとしてKernel page-table isolationがある。

gccとg++でコンパイルとスタック領域りょういきとヒープ領域りょういきに対たいしてはASLRを用もちいるが、コード領域りょういきにASLRを用もちいるにはオプション「-pie」を使つかわねばならない[48]。また共有きょうゆうライブラリにASLRを用もちいるにはオプション「-fPIC」を指定していする[48]。

開発かいはつ時じの対策たいさく

編集へんしゅう

プログラミング言語げんご・プログラミング環境かんきょうの選択せんたく

編集へんしゅう

C言語げんごやC++以外いがいの言語げんごではバッファオーバーフローが発生はっせいしないよう対策たいさくが取とられているものも多おおく、コンパイル時じにバッファオーバーフローのチェックを行おこなったり、実行じっこう時じにバッファオーバーフローに対たいする警告けいこくや例外れいがいを上あげたりするものもある（Ada、Eiffel、LISP、Modula-2、Smalltalk、OCaml、およびC言語げんごから派生はせいしたCycloneやD言語げんごなど）。

Javaプラットフォームや.NET Frameworkでは全すべての配列はいれつに対たいして境界きょうかいチェックが必須ひっすとされる。ほぼすべてのインタプリタ言語げんごではバッファオーバーフローへの対策たいさくが行おこなわれており、エラー発生はっせい時じにはその状態じょうたいが明確めいかくに伝つたえられる。境界きょうかいチェックを行おこなうのに十分じゅうぶんな型かた情報じょうほうを保持ほじしているようなプログラミング言語げんごでは、境界きょうかいチェックの有効ゆうこう・無効むこうを切きり替かえるためのオプションが提供ていきょうされていることもある[注釈ちゅうしゃく 6]。

ソースコード記述きじゅつ時じの対策たいさく

編集へんしゅう

バッファオーバーフロー攻撃こうげきは主おもにC言語げんごやC++を対象たいしょうとしたものなので、以下いかではプログラミング言語げんごとしてC言語げんごかC++を選えらんだ場合ばあいに対たいしての対策たいさくを述のべる。

人手ひとでによる対策たいさく

編集へんしゅう

バッファオーバーフロー攻撃こうげきを防ふせぐには、領域りょういき長ちょうとデータ長ちょうを意識いしきしたプログラミングを行おこなう事ことが重要じゅうようである[51]：

  • データをバッファに挿入そうにゅうする際さいには、データ長ちょうがバッファ長ちょうを超こえない事ことを調しらべる検査けんさロジックをプログラムに書かき加くわえておく[51]
  • データが文字もじ列れつの場合ばあいは文字もじ列れつ長ちょうを数かぞえ間違まちがえないよう、文字もじ列れつの終端しゅうたんにあるナル文字もじも数かぞえる[51]
  • データ長ちょうに依存いぞんしたループを書かくときに間違まちがってループを回まわしすぎる（Off-by-oneエラー）事ことが無ないようにする[51]
  • 事前じぜんにデータ長ちょうの上限じょうげんがわからない場合ばあいは、バッファをmalloc等とうで動的どうてきに確保かくほし、不要ふようになったら確実かくじつにfreeする[51]

安全あんぜんなライブラリの使用しよう

編集へんしゅう

標準ひょうじゅんCライブラリを使つかう代かわりに、バッファあふれを未然みぜんに防ふせいだりエラーとして検出けんしゅつしてくれたりするセキュアなライブラリを使つかう事ことも重要じゅうようである。このようなライブラリとして以下いかのようなものがある。

  • Managed String（Linux環境かんきょう）[51]
  • ISO/IEC 9899:2011 Annex K（Windows環境かんきょう）[51]
  • SafeStr（Linux環境かんきょう、Windows環境かんきょう）[51]
  • "The Better String Library"[52]
  • Vstr[53]
  • Erwin[54]

またBSD libcなど、Cライブラリの実装じっそうによってはstrlcpyやstrlcatといった、より安全あんぜんに配慮はいりょした文字もじ列れつ用よう関数かんすうが用意よういされている。

静的せいてきコード解析かいせき時じにおける対策たいさく

編集へんしゅう

人手ひとでによる静的せいてきコード解析かいせき

編集へんしゅう

静的せいてきコード解析かいせきの際さい、前述ぜんじゅつした領域りょういき長ちょうとデータ長ちょうを意識いしきしたプログラミングが行おこなわれているか再さい確認かくにんし、strcpy, sprintf 等とうのデータ領域りょういき長ちょうを意識いしきしないライブラリ関数かんすうが使用しようされていないか、使用しようされているならその入力にゅうりょく長ちょうの計算けいさんが間違まちがっていないかを確認かくにんする[55]。またヒープオーバーフロー対策たいさくとしてmalloc/freeやnew/deleteの多用たように注意ちゅういし、関数かんすうポインタの書かき換かえを防ふせぐために関数かんすうポインタが多用たように注意ちゅういし[55]、攻撃こうげきパターンを見逃みのがす事ことがないようデータの一部いちぶを切きり捨すてている関数かんすうに注意ちゅういする[55]。

自動じどう化かされた静的せいてきコード解析かいせき

編集へんしゅう

strcpy等とうのバッファオーバーフローが起おこりやすい関数かんすうの使用しように対たいして警告けいこくを出だしてくれる関数かんすう名めい照合しょうごう型がた検査けんさツール[55]や、各種かくしゅソースコード検査けんさツール[55]を使用しようしてバッファオーバーフロー対策たいさくを行おこなう。開発かいはつ環境かんきょうの中なかにはソースコード検査けんさツールをオプションとして備そなえているものもあるので、それを利用りようする事こともできる[55]。

またソースコードが手てに入はいらない製品せいひん等とうを利用りようする場合ばあいは、ファジングツールでブラックボックス解析かいせきする。

発展はってん的てきな攻撃こうげき

編集へんしゅう

Return-to-libc攻撃こうげき

編集へんしゅう
詳細しょうさいは「Return-to-libc攻撃こうげき」を参照さんしょう

既すでに述のべたように、典型てんけい的てきなスタックベースのオーバーフロー攻撃こうげきでは、本来ほんらいデータを格納かくのうすべき箇所かしょにシェルコードやNOP命令めいれいのようなコードを置おき、リターンアドレスを書かき換かえてこれらのコードにジャンプして、これらのコードを実行じっこうする必要ひつようがあった。しかしW Xが実装じっそうされた実行じっこう環境かんきょうではデータを格納かくのうすべき箇所かしょにおけるコード実行じっこうを不ふ許可きょかとしているので、こうしたオーバーフロー攻撃こうげきを仕掛しかける事ことはできない。

そこでW Xを回避かいひする為ために考案こうあんされたのがReturn-to-libc攻撃こうげきである。この攻撃こうげきでは、リターンアドレスのジャンプ先さきをデータ格納かくのう箇所かしょに書かき換かえるのではなく、標準ひょうじゅんCライブラリ(libc)のような共有きょうゆうライブラリ・DLLにジャンプするよう書かき換かえる。こうしたライブラリはデータ格納かくのう箇所かしょ以外いがいに置おかれているので（W Xが実装じっそうされた環境かんきょうにおいても）実行じっこう許可きょかがある。そこで攻撃こうげき者しゃはライブラリ内ないの関数かんすうを悪用あくようして、攻撃こうげきを仕掛しかける事ことができる。

実行じっこう環境かんきょうがASLRを実装じっそうしていれば、libc等とうのライブラリの仮想かそうアドレスはランダムに変かわるので、攻撃こうげき者しゃがジャンプ先さきをライブラリに落おちるようリターンアドレスを書かき換かえるのは困難こんなんになる。

Return-to-Register攻撃こうげき

編集へんしゅう

Return-to-Register攻撃こうげきとは「ret命令めいれい実行じっこう後ごにレジスタが指さしているアドレスに不正ふせいな命令めいれいコードを挿入そうにゅうし、その上うえで”そのレジスタ値ちに実行じっこうを移うつす命令めいれい群ぐんが格納かくのうされているアドレス”でリターンアドレスを書かき換かえる攻撃こうげき」[56]のことである。

例たとえばレジスタAがバッファの先頭せんとうへのポインタを格納かくのうしているとすると、そのときレジスタAをオペランドにとる任意にんいのjumpまたはcall命令めいれいが実行じっこうフローの支配しはい権けんを得えるのに使用しようできる[57]。

ret2esp攻撃こうげき

編集へんしゅう

ret2esp（Return to esp）攻撃こうげきは、2017年ねん現在げんざいのASLRの実装じっそうのデフォルトではコード領域りょういき（.textセクション）をランダマイズしない事ことを利用りようしてASLRを回避かいひする攻撃こうげき手法しゅほうである[58]。ここでespはx86におけるスタックポインタである。この攻撃こうげきは.textセクション内ないに「jmp esp」のような命令めいれいがある場合ばあいに成立せいりつする[58]。攻撃こうげき者しゃはバッファオーバーフローを利用りようしてespの（仮想かそうアドレス空間くうかん上じょうの）下したにシェルコードを配置はいちした上うえで、リターンアドレスを「jmp esp」の箇所かしょに書かき換かえる。するとまずリターンアドレスの書かき換かえにより「jmp esp」のところにジャンプし、次つぎに「jmp esp」が実行じっこうされてespの箇所かしょにジャンプするので、その下したに配置はいちしたシェルコードが実行じっこうされる事ことになる[58]。

歴史れきし

編集へんしゅう

バッファオーバーフローがある程度ていど公おおやけに文書ぶんしょ化かされたのは1972年ねんの初はじめで[独自どくじ研究けんきゅう?]、Anderson 1972 で以下いかのように説明せつめいされている。

Anderson 1972, p. 61: The code performing this function does not check the source and destination addresses properly, permitting portions of the monitor to be overlaid by the user. This can be used to inject code into the monitor that will permit the user to seize control of the machine.

この処理しょりを実行じっこうするコードは読よみ込こみ元もとと書かき込こみ先さきのアドレスに対たいするチェックを適切てきせつに行おこなっておらず、モニターの一部いちぶに対たいしユーザによる上書うわがきを許ゆるすことになっている。これはモニターにコードを挿入そうにゅうするのに利用りようされる可能かのう性せいがあり、結果けっかとしてユーザがマシンの制御せいぎょを掌握しょうあくする可能かのう性せいがある。

モニターとは、現在げんざいカーネルと呼よばれているのと同おなじものである。

バッファオーバーフローを利用りようした悪意あくいのあるエクスプロイトで最初さいしょに文書ぶんしょ化かされたのは、1988年ねんに書かかれたMorris wormがインターネット上じょうで増殖ぞうしょくするのに利用りようしていたエクスプロイトのうちの一ひとつである。攻撃こうげき対象たいしょうのプログラムはUNIXのサービスであるfingerであった[59]。 1995年ねん、Thomas Lopaticはそれとは独立どくりつにバッファオーバーフローを発見はっけんし、セキュリティに関かんするメーリングリストBugtraqへ投稿とうこうした[60]。 1996年ねん、エリアス・レヴィ（ハンドルネームAleph one）はオンラインマガジンPhrackで記事きじ"Smashing the Stack for Fun and Profit"を発表はっぴょうした[61]。 これはスタックベースのバッファオーバーフローを使用しようしたエクスプロイトを手順てじゅんを追おって説明せつめいしていく内容ないようである。

これ以降いこう、少すくなくとも2つの有名ゆうめいなインターネットワームがバッファオーバーフローを利用りようしたエクスプロイトで多おおくのシステムに被害ひがいを与あたえている。2001年ねんにはCode RedがマイクロソフトのInternet Information Services (IIS) 5.0のバッファオーバーフローを利用りようしている[62]。 また2003年ねんにはSQL SlammerがMicrosoft SQL Server 2000の動作どうさするマシンに被害ひがいを与あたえている[63]。

2003年ねんには、市販しはんのXboxのゲームに含ふくまれるバッファオーバーフローが利用りようされ、無認可むにんかのソフトウェア（例たとえばHomebrewのゲームなど）をModチップなどのハードウェアの改造かいぞうなしに動作どうささせるのに利用りようされた[64]。 PlayStation 2では同おなじ目的もくてきのためにPS2 Independence Exploitが使用しようされる。またWiiではHomebrewが利用りようされるが、これはゼルダの伝説でんせつ トワイライトプリンセスに存在そんざいするバッファオーバーフローを利用りようしている。

参考さんこう文献ぶんけん

編集へんしゅう

関連かんれん項目こうもく

編集へんしゅう

脚注きゃくちゅう

編集へんしゅう
[脚注きゃくちゅうの使つかい方かた]

注釈ちゅうしゃく

編集へんしゅう
  1. ^ i386の場合ばあい、Windowsであれば仮想かそう空間くうかんの上位じょうい2 GB、Linuxであれば仮想かそう空間くうかんの上位じょうい1 GBがカーネル空間くうかんになる。なお本節ほんぶしで書かいたメモリ箇所かしょはいずれも後述こうじゅつするセキュリティ技術ぎじゅつアドレス空間くうかん配置はいちのランダム化か (ASLR) を用もちいていない場合ばあいの話はなしである。
  2. ^ Block Started by Symbolというアセンブラの疑似ぎじ命令めいれいに由来ゆらいする。
  3. ^ なお、データ領域りょういきとbss領域りょういきを合あわせて静的せいてき領域りょういきという。
  4. ^ x86ではebpレジスタ (Stack Base Pointer Register)。
  5. ^ 命令めいれいポインタとも。x86ではeipレジスタ (Extended Instruction Pointer)。
  6. ^ 例たとえばDelphiでは$RangeChecksディレクティブで境界きょうかいチェックの有効ゆうこう・無効むこうを切きり替かえられる[49][50]。

出典しゅってん

編集へんしゅう
  1. ^ a b 八木はちぼく, 村山むらやま & 秋山あきやま 2015, p. 59.
  2. ^ “第だい10章しょう 著名ちょめいな脆弱ぜいじゃく性せい対策たいさくバッファオーバーフロー: #1 概要がいよう”. セキュアプログラミング講座こうざ C/C++言語げんご編へん 旧きゅう2007年ねん公開こうかい版ばん. 情報処理じょうほうしょり推進すいしん機構きこう. 2018年ねん12月14日にち閲覧えつらん。
  3. ^ “[迷信めいしん] scanf ではバッファオーバーランを防ふせげない”. C/C++迷信めいしん集しゅう. 株式会社かぶしきがいしゃきじねこ. 2020年ねん1月がつ12日にち時点じてんのオリジナルよりアーカイブ。2010年ねん2月がつ28日にち閲覧えつらん。 “書式しょしき指定していが不適切ふてきせつなために発生はっせいする脆弱ぜいじゃく性せいであって、scanf の問題もんだいではありません。”
  4. ^ a b c d e f g h i j k l m n “CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')”. Mitre. 2018年ねん12月18日にち閲覧えつらん。
  5. ^ a b c d e f g h i “CWE-121: Stack-based Buffer Overflow”. Mitre. 2018年ねん12月18日にち閲覧えつらん。
  6. ^ a b c d e f g h i j “CWE-122: Heap-based Buffer Overflow”. Mitre. 2018年ねん12月18日にち閲覧えつらん。
  7. ^ a b “CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer”. Mitre. 2018年ねん12月18日にち閲覧えつらん。
  8. ^ “CWE-787: Out-of-bounds Write”. Mitre. 2018年ねん12月18日にち閲覧えつらん。
  9. ^ “CWE-193: Off-by-one Error”. Mitre. 2018年ねん12月18日にち閲覧えつらん。
  10. ^ “CWE-131: Incorrect Calculation of Buffer Size”. Mitre. 2018年ねん12月18日にち閲覧えつらん。
  11. ^ “CWE-680: Integer Overflow to Buffer Overflow”. Mitre. 2018年ねん12月18日にち閲覧えつらん。
  12. ^ “The Exploitant - Security info and tutorials”. 2009年ねん11月29日にち閲覧えつらん。
  13. ^ a b Erickson 2011, pp. 87–88.
  14. ^ a b c d Erickson 2011, p. 84.
  15. ^ a b c d 八木はちぼく, 村山むらやま & 秋山あきやま 2015, pp. 60–61.
  16. ^ a b c d e f g Erickson 2011, pp. 161–164.
  17. ^ 八木はちぼく, 村山むらやま & 秋山あきやま 2015, p. 64.
  18. ^ Akritidis, P.; Markatos, Evangelos P.; Polychronakis, M.; Anagnostakis, Kostas D. (2005). "STRIDE: Polymorphic Sled Detection through Instruction Sequence Analysis." (PDF). Proceedings of the 20th IFIP International Information Security Conference (IFIP/SEC 2005). IFIP International Information Security Conference.
  19. ^ Erickson 2011, pp. 164–168.
  20. ^ Erickson 2011, pp. 168–173.
  21. ^ a b c 八木はちぼく, 村山むらやま & 秋山あきやま 2015, pp. 65–67.
  22. ^ “The Metasploit Opcode Database”. 2007年ねん5月がつ12日にち時点じてんのオリジナルよりアーカイブ。2007年ねん5月がつ15日にち閲覧えつらん。
  23. ^ Erickson 2011, pp. 173–179.
  24. ^ a b c d e f g 角すみ馬うま 文彦ふみひこ（技術ぎじゅつ本部ほんぶ クラウド基盤きばんエキスパート） (2007年ねん11月30日にち). “malloc(3)のメモリ管理かんり構造こうぞう”. VA Linux Systems Japan. 2018年ねん12月26日にち閲覧えつらん。
  25. ^ Doug Lea. “A Memory Allocator”. 2018年ねん12月26日にち閲覧えつらん。
  26. ^ a b c FFRI 2013, p. 7.
  27. ^ a b FFRI 2013, p. 8.
  28. ^ a b c d e f “CWE-123: Write-what-where Condition”. Mitre. 2018年ねん12月26日にち閲覧えつらん。
  29. ^ “JVNDB-2015-004721 Silicon Integrated Systems WindowsXP Display Manager における権限けんげんを取得しゅとくされる脆弱ぜいじゃく性せい”. JVN iPedia. 2018年ねん12月26日にち閲覧えつらん。
  30. ^ a b Erickson 2011, pp. 179–192.
  31. ^ 芝しば国雄くにお (2006年ねん9月がつ5日にち). “第だい14回かい: バッファオーバーフローとサーバ側がわのセキュリティ対策たいさくを考かんがえる”. ThinkIT. オープンソースの適用てきよう可能かのう性せいを示しめす. p. 2. 2019年ねん1月がつ1日にち閲覧えつらん。
  32. ^ David Wheeler (2004年ねん1月がつ27日にち). “セキュアなプログラマー バッファー・オーバーフローに対抗たいこうする 今日きょう最大さいだいの脆弱ぜいじゃく性せいを防止ぼうしする”. IBM. 2019年ねん1月がつ1日にち閲覧えつらん。
  33. ^ a b c 八木はちぼく, 村山むらやま & 秋山あきやま 2015, pp. 69–70.
  34. ^ “StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks by Cowan et al.” (PDF). 2012年ねん2月がつ9日にち閲覧えつらん。
  35. ^ “/GS (バッファーのセキュリティ チェック)” (2016年ねん11月4日にち). 2012年ねん2月がつ9日にち閲覧えつらん。
  36. ^ “Libsafe - Free Software Directory”. 2012年ねん2月がつ9日にち閲覧えつらん。
  37. ^ a b c d e 八木はちぼく, 村山むらやま & 秋山あきやま 2015, pp. 71–73.
  38. ^ “Windows XP Service Pack 2、Windows XP Tablet PC Edition 2005、および Windows Server 2003 のデータ実行じっこう防止ぼうし (DEP) 機能きのうの詳細しょうさい”. 2012年ねん2月がつ17日にち閲覧えつらん。
  39. ^ “Bypassing Windows Hardware-enforced Data Execution Prevention”. 2007年ねん5月がつ20日はつか閲覧えつらん。
  40. ^ “PaX: Homepage of the PaX team”. 2012年ねん2月がつ17日にち閲覧えつらん。
  41. ^ “KernelTrap.Org”. 2012年ねん5月がつ29日にち時点じてんのオリジナルよりアーカイブ。2012年ねん2月がつ17日にち閲覧えつらん。
  42. ^ “Openwall Linux kernel patch 2.4.34-ow1”. 2012年ねん2月がつ17日にち閲覧えつらん。
  43. ^ “BufferShield: Prevention of Buffer Overflow Exploitation for Windows”. 2012年ねん2月がつ17日にち閲覧えつらん。
  44. ^ “NGSec Stack Defender”. 2007年ねん5月がつ13日にち時点じてんのオリジナルよりアーカイブ。2012年ねん2月がつ17日にち閲覧えつらん。
  45. ^ a b “NXビット”. IT用語ようご辞典じてんe-Words. 2019年ねん1月がつ1日にち閲覧えつらん。
  46. ^ “Linux kernel 3.14, Section 1.7. Kernel address space randomization”. kernelnewbies.org (2014年ねん3月がつ30日にち). 2014年ねん4月がつ2日にち閲覧えつらん。
  47. ^ Stefan Esser. “iOS 6 Exploitation 280 Days Later”. 2019年ねん1月がつ1日にち閲覧えつらん。
  48. ^ a b “Hardening”. Devian. 2019年ねん1月がつ1日にち閲覧えつらん。
  49. ^ Neil Moffatt. “Delphi Basics : $RangeChecks command”. 2012年ねん2月がつ3日にち閲覧えつらん。
  50. ^ 範囲はんいチェック - RAD Studio
  51. ^ a b c d e f g h “第だい10章しょう 著名ちょめいな脆弱ぜいじゃく性せい対策たいさく　バッファオーバーフロー: #2 ソースコード記述きじゅつ時じの対策たいさく”. セキュアプログラミング講座こうざ(2007年ねん公開こうかい版ばん). 情報処理じょうほうしょり推進すいしん機構きこう. 2018年ねん12月27日にち閲覧えつらん。
  52. ^ “The Better String Library”. 2012年ねん2月がつ8日にち閲覧えつらん。
  53. ^ “The Vstr Homepage”. 2012年ねん2月がつ8日にち閲覧えつらん。
  54. ^ “The Erwin Homepage”. 2012年ねん2月がつ8日にち閲覧えつらん。
  55. ^ a b c d e f “第だい10章しょう 著名ちょめいな脆弱ぜいじゃく性せい対策たいさく　バッファオーバーフロー: #3 ソースコードの静的せいてき検査けんさ”. セキュアプログラミング講座こうざ(2007年ねん公開こうかい版ばん). 情報処理じょうほうしょり推進すいしん機構きこう. 2018年ねん12月27日にち閲覧えつらん。
  56. ^ メモリ破損はそん脆弱ぜいじゃく性せいに対たいする攻撃こうげきの調査ちょうさと分類ぶんるい 2014, p. 769.
  57. ^ Shah, Saumil (2006). 1 - Saumil Shah - Writing Metasploit Plugins.pdf "Writing Metasploit Plugins: from vulnerability to exploit" (PDF). Hack In The Box. Kuala Lumpur. {{cite conference}}: |url=の値ねが不正ふせいです。 (説明せつめい)
  58. ^ a b c “CTFで学まなぶ脆弱ぜいじゃく性せい（スタックバッファオーバーフロー編へん・その1）”. NTTデータ先端せんたん技術ぎじゅつ株式会社かぶしきがいしゃ. 2019年ねん1月がつ1日にち閲覧えつらん。
  59. ^ “"A Tour of The Worm" by Donn Seeley, University of Utah”. 2007年ねん5月がつ20日はつか時点じてんのオリジナルよりアーカイブ。2007年ねん6月がつ3日にち閲覧えつらん。
  60. ^ “Bugtraq security mailing list archive”. 2007年ねん9月がつ1日にち時点じてんのオリジナルよりアーカイブ。2007年ねん6月がつ3日にち閲覧えつらん。
  61. ^ “Smashing the Stack for Fun and Profit”. 2007年ねん6月がつ3日にち閲覧えつらん。
  62. ^ “eEye Digital Security”. 2007年ねん6月がつ3日にち閲覧えつらん。
  63. ^ “Microsoft Technet Security Bulletin MS02-039”. 2007年ねん6月がつ3日にち閲覧えつらん。
  64. ^ “Hacker breaks Xbox protection without mod-chip”. 2007年ねん9月がつ27日にち時点じてんのオリジナルよりアーカイブ。2007年ねん6月がつ3日にち閲覧えつらん。
「https://ja.wikipedia.org/w/index.php?title=バッファオーバーフロー&oldid=97564955」から取得しゅとく