stanford-oval/wikipedia huggingface dataset:
イスラム原理主義
表現の起源

日本では一般に原理主義と翻訳されるようになったファンダメンタリズムという言葉は、本来は1920年代のアメリカ合衆国で、聖書の近代的な文献批評に反対する保守的なキリスト教徒たちが自分たちをファンダメンタリストと自称したものであり、ファンダメンタリズムはその神学的立場を表す「固有名詞」であった。後には、当事者でない人々からの他称ないし一種の蔑称としても使われるようになり、ダーウィンの進化論を認めず、これを学校教育で扱うことに反対したような人々がファンダメンタリストのレッテルを貼られた。
アメリカ合衆国では、1979年のイラン・イスラム革命でアメリカ合衆国の傀儡政権であったパフラヴィー政権が打倒され、イスラム法に基づいて統治する革命政権が樹立された時に、革命政権を敵視して、本来はアメリカ合衆国のキリスト教における一つの神学的立場を表す固有名詞であるファンダメンタリズムを、教典の原典を無謬と信じ、著しく極端な教義を主張し追求する、狂信的な運動や思想という意味に一般名詞化し、イスラムと連結して Islamic Fundamentalism という表現を作り、イスラム革命政権に対して敵対や侮蔑の感情を込めて[誰が?]使用し始めた。
言葉の用法としては、第二次世界大戦時の交戦相手である日本軍・日本人に対する「ジャップ」や、ベトナム戦争時の南ベトナム解放民族戦線や北ベトナム軍に対する「ベトコン」などと同じである。
その後、アメリカ合衆国の国民・報道・議会・政府などは、イスラム原理主義という表現を、ハマース、ヒズボラ、ムスリム同胞団、ターリバーン、アルカーイダなどに対しても使用するようになった。
アメリカ合衆国の公的言説では、イスラム法に基づいて統治をしている国家・社会・政府・政党、イスラム法による統治を目ざす政党・団体であっても、サウジアラビアのように、アメリカ合衆国の同盟国や友好国、友好政党・団体に対しては、イスラム原理主義という表現は使用されない。
ムスリム側の表現

イスラム原理主義は、世俗化に抗して社会活動や政治活動を通じてイスラームの復興やイスラームによる統治を求める「イスラーム復興運動」や「イスラーム主義」に対して、キリスト教徒などの非ムスリムがイスラムという言葉とキリスト教の神学用語に起源をもつ言葉とを結びつけて呼んだ表現であり、当事者（イスラーム主義者）による自称ではない。アラビア語ではイスラーム主義者はイスラーミー、原理主義者はウスーリーユーンである。
言葉が使用される対象

イラン・イスラム革命後のイラン、ハマース、ヒズボラ、ムスリム同胞団、ターリバーン、アル・カーイダ、ISIL
イスラム集団、武装イスラム集団、イスラム聖戦、ラシュカレトイバ、ジェマ・イスラミア
関連図書

井上順孝、大塚和夫『ファンダメンタリズムとは何か』新曜社、1994年。ISBN 978-4788504943。
サイイド・クトゥブ『イスラーム原理主義の「道しるべ」』岡島稔・座喜純（訳・解説）、第三書館、2998年。ISBN 978-4-8074-0815-3。
内藤正典『イスラームから世界を見る』筑摩書房〈ちくまプリマー新書〉、2012年。ISBN 978-4480688859。
松本健一『原理主義』風人社、1992年。ISBN 978-4938643065。
バッファオーバーフロー

バッファオーバーフロー（英: buffer overflow）またはバッファオーバーラン（英: buffer overrun）は、コンピュータのプログラムにおけるバグのひとつ、またはそれにより引き起こされる現象で、プログラムがバッファに割り当てられた空間よりも大きなデータを書き込むことで、データがバッファ境界からあふれ、バッファの範囲外のメモリを上書きし、元々そのメモリにあったデータを破壊してしまうことを指す。
バッファオーバーフローは、上書きされるメモリ領域がスタック領域なのかヒープ領域なのかに応じてそれぞれスタックベースのバッファオーバーフロー、ヒープベースのバッファオーバーフローと呼ばれる。なお、名称が似ているスタックオーバーフローとは別の現象である。
サイバーセキュリティ・情報セキュリティの分野では、バッファオーバーフローはメモリ破壊系の脆弱性の一つとして知られ、攻撃者がバッファオーバーフロー脆弱性のあるプログラムに意図的に悪意のあるデータ（コード）を与えることにより、コンピュータの制御を乗っ取ってしまうことを可能にする。バッファオーバーフロー脆弱性を悪用した攻撃をバッファオーバーフロー攻撃という。
バッファオーバーフローの具体例 > 簡単な例

以下の例では、プログラム中の隣接したアドレスに2つのデータ項目が定義されている。一つは 8 バイトの文字列バッファ A、もう一つは 2 バイトの整数 B である。初期状態では、A は 0 で初期化されており可読な文字は入っていない。また、B には整数 1,979 が格納されている。文字のバイト幅は 1 バイトとする。また、エンディアンはビッグエンディアンとする。
| 変数名 | A | A | A | A | A | A | A | A | B | B |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 値 | NUL | NUL | NUL | NUL | NUL | NUL | NUL | NUL | 1979 | 1979 |
| 16進数値 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 07 | BB |
ここで、プログラムがバッファ A にヌル終端文字列「excessive」を書きこもうとした場合を考える。文字列の長さチェックが行われていないと、この処理で B の値が上書きされてしまう。
| 変数名 | A | A | A | A | A | A | A | A | B | B |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 値 | 「e」 | 「x」 | 「c」 | 「e」 | 「s」 | 「s」 | 「i」 | 「v」 | 25856 | 25856 |
| 16進数値 | 65 | 78 | 63 | 65 | 73 | 73 | 69 | 76 | 65 | 00 |
プログラマとしては B を変更する意図はなかったが、B の値は文字列の一部で置き換えられてしまった。この例ではビッグエンディアンとASCIIコードを仮定しているため、文字「e」とゼロというバイト列は整数 25,856 として解釈される。ここで、仮にプログラム中で A と B 以外にデータ項目変数が定義されていないとものすると、さらに長い文字列を書き込んで B の終端を超えた場合にはセグメンテーション違反などのエラーが発生してプロセスが終了する。
バッファオーバーフローの具体例 > 電子メールアドレスを題材にした例

コンピュータプログラムを作るとき、固定長のバッファとよばれる領域を確保してそこにデータを保存するという手法がよく使われる。
たとえば、電子メールアドレスは200文字を超えないだろうと予想して
200文字分の領域をバッファとして用意する。
ユーザが200文字より長いメールアドレスを入力する。
プログラムがバッファの大きさをチェックせずに入力データを書き込む。
バッファとして確保した領域をはみだしてデータが書き込まれてしまう。
これがバッファオーバーフローである。仮にはみ出した部分にプログラムの動作上意味を持つデータがあれば、これを上書きして破壊することにより、プログラムはユーザの意図しない挙動を示すであろう。
このようにバッファオーバーフローは、プログラムが用意したバッファの大きさを超えてデータを書き込んでしまうバグである。
バッファオーバーフローの具体例 > C言語特有の例

C言語の標準入出力関数であるgets関数はバッファ長のチェックを行わないで標準入力をバッファに書き込むので、この関数を使う全てのプログラムには、バッファオーバーフローによる不正動作の危険性がある。また使い方が分かりやすいという理由でC言語初心者向けの入門プログラミングでしばしば用いられるscanf関数も書式指定を誤った場合は同じ危険性を持っている。これらの関数を実用的なプログラムで用いる場合には注意が必要である。
次のプログラムは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などと同様、メモリ破壊系の脆弱性に相当する。
共通脆弱性タイプCWEには、
| 番号 | 名称 |
| --- | --- |
CWE-120: 入力サイズをチェックしないバッファのコピー（古典的バッファオーバーフロー）
CWE-121: スタックベースのバッファオーバーフロー
CWE-122: ヒープベースのバッファオーバーフロー
などが登録されており、これら3つはいずれも「CWE-119: メモリバッファの境界内における操作の不適切な制限」に属している。
これら3つのバッファオーバーフロー脆弱性が頻繁に生じるのはC言語やC++であり、古典的バッファオーバーフローはアセンブリ言語でも生じる。
これら3種類のバッファオーバーフローはセキュリティポリシーの外側で任意のコードを攻撃者に実行可能にする事が頻繁にある。さらに任意のコードの実行により他のセキュリティサービス機構を破壊する事も可能になる。またこれら3種類のバッファオーバーフローはクラッシュの原因にもなるので、意図的にクラッシュさせる攻撃が可能になる。
CWEでは「CWE-193: Off-by-oneエラー」がバッファオーバーフローの原因になると述べられており、整数オーバーフローもバッファオーバーフローの原因になる事が述べられている。
バッファオーバーフロー攻撃 > 古典的バッファオーバーフロー攻撃

バッファAの値を他のバッファBにコピーするとき、BのバッファサイズがAのバッファサイズよりも大きいことをチェックしない場合に生じる脆弱性である。この脆弱性は、プログラマーがこのようなチェックの実装を怠った事により生じる。これはプログラマーが最低限のセキュリティチェックすらしていないことを強く示唆する。
脆弱性の具体例としては、例えばC言語やC++において、配列サイズをチェックする事なく、配列にstrcpyやscanfで文字列等をコピーするといったものがある。攻撃者は意図的に大きな入力をstrcpy、scanf、getsに与えることで、古典的バッファオーバーフローを不正に生じさせる事ができる。
例えば攻撃者がバッファAをバッファオーバーフローさせる事により、Aの隣りにある変数xを不正に変更できた場合、xがセキュリティ上重要なデータ（例えば管理者権限を持っているか否かを判定するビットを保持している）であれば、セキュリティ上重要な問題が生じる。
バッファオーバーフロー攻撃 > スタックベースのバッファオーバーフロー攻撃

スタックベースのバッファオーバーフローは「上書きされるバッファがスタック（すなわち、局所変数や、まれに関数のパラメータ）にアロケートされる」事が可能な場合に生じる脆弱性である。このような脆弱性はファジングを使用して発見されることが多い。
バッファオーバーフロー攻撃 > スタックベースのバッファオーバーフロー攻撃 > C言語・C++におけるメモリ領域

スタックベースのバッファオーバーフローについて説明するためにプロセスのメモリ利用方法を復習する。オペレーティングシステム (OS) は各ユーザプロセスに仮想アドレス空間を割り振り、WindowsやLinuxなどのOSでは上位のアドレスをカーネルが使うカーネル空間とし、残りをユーザプロセス自身が用いるユーザ空間とする。カーネル空間はユーザプロセスがアクセスする事はできず、通常のプログラミングでは意識する事はない。
C言語やC++で書かれたプログラムの場合、ユーザ空間をさらに分割する。これらの言語で書かれたプログラムでは、仮想アドレスの最低位の箇所から順にプログラムの実行コードを置くコード領域（テキスト領域とも）、初期化された静的変数・大域変数を置くデータ領域、初期化されていない静的変数・大域変数を置くbss領域、malloc等で動的に確保されたメモリを置く（可変サイズの）ヒープ領域を確保する。
一方、ユーザ空間における仮想アドレスの最高位の箇所は関数のコールスタックを保存する（可変サイズの）スタック領域として用いられる。
| 0 | 1 | 2 | 3 | 4 | 5 |
| --- | --- | --- | --- | --- | --- |
| 最低位 | … | … | … | … | 最高位 |
| コード領域 | 静的領域 | 静的領域 | ヒープ領域 （高位に向かって成長→） | … | スタック領域 （←低位に向かって成長） |
| コード領域 | データ領域 | bss領域 | ヒープ領域 （高位に向かって成長→） | … | スタック領域 （←低位に向かって成長） |
スタック領域はプロセス中で呼ばれる関数のコールスタックを格納する領域で、コールスタック中の各関数のデータ（スタックフレームという）を並べて格納している。プロセス中で関数fが関数gを呼び出した場合、コールスタックは以下のようになる：
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 低位アドレス | … | … | … | … | … | … | … | 高位アドレス |
| … | gのスタックフレーム | gのスタックフレーム | gのスタックフレーム | gのスタックフレーム | fのスタックフレーム | fのスタックフレーム | fのスタックフレーム | … |
| … | gの処理に必要な一時的な情報 | gの局所変数 | gのSFP | gのリターンアドレス | gの引数の値 | fの処理に必要な一時的な情報 | … | … |
プロセスで現在実行中の関数のスタックフレームの位置を覚えるためにプロセッサによって用いられるのがフレームポインタで、具体的には（現在実行中の関数がgであれば）gのSFPのアドレスを指している。SFPは関数呼び出し時に呼び出し元の関数のフレームポインタのアドレスを覚えるための領域で、fがgを呼び出した際、スタックフレームの値（＝fのSFPのアドレス）をgのSFPに格納する。なお、SFPは「Saved Frame Pointer」の略で、日本語訳は「退避されたフレームポインタ」である。
一方gのリターンアドレスは呼び出し元関数fのプログラムカウンタのアドレスを格納する。
バッファオーバーフロー攻撃 > スタックベースのバッファオーバーフロー攻撃 > 攻撃の基本的アイデア

今例えば、関数gはユーザから（ASCIIコードの）文字列を入力を受け取り、入力された文字列を配列char A[10]に格納するとする。Aのサイズは10であるので、関数gのプログラマはユーザから受け取った文字列をAに格納する前に、その文字列が本当に10文字以下なのかをチェックする機構をgに実装しておかねばならない。このようなチェック機構を実装するのを忘れていた場合、悪意のあるユーザ（以下、「攻撃者」と呼ぶ）によりスタックベースのバッファオーバーフロー攻撃を受けてしまう危険がある。
具体的には、攻撃者は以下のような文字列をgに入力する：
（シェルコード）…（シェルコードの仮想アドレス）
ここでシェルコードとは、何らかの悪意のある短いプログラムで、例えば攻撃者のためにバックドアを開けたり、マルウェアのダウンロードを行ったりする。
この文字列が配列Aの先頭から順に書き込まれていくと、A[i]のアドレスはiが大きいほど大きくなるので、攻撃者が入力文字列の長さを適切に選べば、アドレス空間には以下のようにデータが書き込まれ、gのリターンアドレスがシェルコードの仮想アドレスに上書きされる：
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 低位アドレス | … | … | … | … | … | … | … | 高位アドレス |
| … | gのスタックフレーム | gのスタックフレーム | gのスタックフレーム | gのスタックフレーム | fのスタックフレーム | fのスタックフレーム | fのスタックフレーム | … |
| … | gの処理に必要な一時的な情報 | gの局所変数 | gのSFP | gのリターンアドレス | gの引数の値 | fの処理に必要な一時的な情報 | … | … |
|  |  | (シェルコード)… | … | （シェルコードの仮想アドレス） |  |  |  |  |
よって関数gが終了したとき、gのリターンアドレス（の箇所に上書きされたシェルコードの仮想アドレス）が読み込まれるので、プログラムカウンタはシェルコードの位置にジャンプし、攻撃者の狙い通り、シェルコードが実行される事になる。
バッファオーバーフロー攻撃 > スタックベースのバッファオーバーフロー攻撃 > NOPスレッド

上で述べた攻撃のアイデアが実行可能であるためには、攻撃者がリターンアドレスに上書きすべき仮想アドレスを正確に知り、それを関数gに入力する必要があるが、スタックは動的に変化するため、これは容易ではない。そこで本節ではリターンアドレスに上書きすべき仮想アドレスの「おおよその値」さえ分かれば攻撃が可能になるテクニック（NOPスレッド）を述べる。
NOPとは「何も行わない」事を意味するアセンブリ命令で、本来はタイミングを合わせるなどの動機により何もせずにCPU時間を消費するために用いられる。NOPスレッド(sled、そり)とはこのNOP命令を複数個並べたもので、これを利用する事により攻撃対象の関数をシェルコードの位置まで滑走させる。
具体的には攻撃者は下記のような文字列を攻撃対象の関数gに入力する：
NOP  … NOP (シェルコード)(戻りアドレス)…(戻りアドレス)
最初の「NOP … NOP」の部分がNOPスレッドである。攻撃者がNOPスレッドの長さや戻りアドレスの繰り返し回数を適切に選んでgに入力すると、スタック領域は例えば以下のようになる（攻撃に関係する部分だけ抜書き）：
| 0 | 1 | 2 | 3 | 4 |
| --- | --- | --- | --- | --- |
| gのスタックフレーム | gのスタックフレーム | gのスタックフレーム | gのスタックフレーム | fのスタックフレーム |
| … | gの局所変数 | gのSFP | gのリターンアドレス | … |
| … | NOP… NOP … | NOP …NOP  (シェルコード)…(戻りアドレス)…(戻りアドレス) | (戻りアドレス) | (戻りアドレス)… |
これでgのリターンアドレスは「戻りアドレス」にセットされるので、攻撃者が「戻りアドレス」としてNOPスレッド部分のアドレスを指定する事に事前に成功していれば、gの終了時にNOPスレッドへとプログラムカウンタが移動する。するとプログラムはNOPを順に実行して右へ右へと移動し、シェルコードの位置にたどり着いてシェルコードが実行されるので、攻撃成功となる。戻りアドレスがNOPスレッドのどこかに落ちさえすればよいので、前節で述べた攻撃違い、リターンアドレスにセットする値を完璧に制御する必要はなく、NOPスレッドの長さ分の誤差が発生しても攻撃が成功する事になる。
NOPスレッドは頻繁に使用されるため、多くの侵入防止システムベンダーでシェルコードの判定に使用されている。このため、エクスプロイトの作成者側では、シェルコードの実行に影響を及ぼさない（NOP以外の）任意の命令をランダムに選んでスレッドを構成することが常套手段となっている。
バッファオーバーフロー攻撃 > スタックベースのバッファオーバーフロー攻撃 > 戻りアドレスの値の予想

攻撃を実行するには、あとは「戻りアドレス」として具体的にどの程度の値を代入すればよいかを知ればよい。しかし攻撃の標的となる組織の環境で戻りアドレスの絶対アドレスがいくつ程度の値になるのかを事前に知る事は難しい。そこで相対アドレスを利用して戻りアドレスを適切に選ぶ攻撃テクニックを紹介する。この攻撃のシナリオでは、攻撃者はシェルコードを含んだ攻撃用のプログラムh（をコンパイルして作った実行コード）を攻撃の標的となる組織に送りつけ、hのサブルーチンとしてgを呼び出す事で攻撃を行う。
この攻撃用プログラムhでは、変数xを宣言が宣言されているものとする。hが標的の環境でgを呼び出したとき、gのスタックフレームはスタック領域上でhのスタックフレームのすぐ隣に配置される事から、攻撃用文字列を入れ込むgの変数の絶対アドレスvar_addは
var_add = &x - (小さな値)
になるはずである。ここで「&x」はxのアドレスを表す。既に述べたようにNOPスレッドを使った攻撃では戻りアドレスとしてvar_add近辺の値を選べば成功するので、攻撃者はこの「小さな値」を決定しさえすればよい。
よって攻撃者は関数gの実行コードを事前に入手し、(シェルスクリプト等を使って)NOPスレッドの長さや戻りアドレスを変えながら攻撃対象のプログラムを何度も実行することで適切な「小さな値」を選び、その「小さな値」を攻撃用プログラムhに書き込んでおけばよい。
バッファオーバーフロー攻撃 > スタックベースのバッファオーバーフロー攻撃 > 埋め込めるコード量が小さい場合の対処

関数gに埋め込む攻撃用の文字列は「NOPスレッド+シェルコード+戻りアドレスの繰り返し」という形をしており、gのリターンアドレスが「戻りアドレスの繰り返し」の部分に落ちない限り攻撃は成功しないので、関数gに攻撃用文字列を埋め込む箇所とgのリターンアドレスとが（仮想アドレス空間上で）あまりに近い場合は、攻撃に必要な長さのシェルコードを埋め込めないという問題が攻撃者に生じる。
しかし攻撃者が攻撃の標的となるマシンの環境変数を設定できる状況下では、攻撃者はこの問題を回避した攻撃が可能である。標的マシンでプロセスが実行される際には、そのプロセスの仮想アドレス空間に環境変数が読み込まれるので、攻撃者が事前に標的マシンの環境変数に「NOPスレッド+シェルコード」を書き込んでおけば、プロセスの仮想アドレスに「NOPスレッド+シェルコード」ができあがる事になる。プロセス中で関数gが実行された際、攻撃者は攻撃用文字列をgに入力して、リターンアドレスをそのNOPスレッドに書き換えれば攻撃が成功する事になる。
より確実な攻撃方法として、攻撃プログラムhの中に環境変数を読み込む関数（getenv()等）を用いるものもある。
バッファオーバーフロー攻撃 > スタックベースのバッファオーバーフロー攻撃 > ヒープスプレー

→詳細は「」を参照
NOPスレッドを長くしすぎると、gのリターンアドレスの位置にすらNOPが書き込まれてしまって攻撃に失敗する為、NOPスレッドを長くして攻撃成功率を上げる手法には限界がある。しかし攻撃者がプロセスのヒープ領域の値をも自由に操れるという条件下では、攻撃者はヒープスプレーというテクニックを用いる事により、この限界を突破した攻撃を行う事が可能になる。
ヒープスプレーでは、NOPスレッドとシェルコードを、スレッド領域ではなくヒープ領域に埋め込み、戻りアドレスとしてヒープ領域中のNOPスレッドを指定する。ヒープ領域上のNOPスレッドにはスレッド領域のNOPスレッドと違い前述した長さの上限が存在しないため、「長いNOPスレッド＋シェルコード」の組み合わせを大量にヒープ中に書き込むことで攻撃成功率を上げる。
ウェブブラウザではJavaScriptなどのクライアントサイドスクリプトにより任意の長さのヒープを作成できるので、ブラウザを対象にしたドライブバイダウンロード攻撃ではヒープスプレーが使われる事が多い。
バッファオーバーフロー攻撃 > スタックベースのバッファオーバーフロー攻撃 > トランポリング

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

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

より高度なヒープベースバッファオーバーフロー攻撃手法を説明する為の準備として、mallocのメモリ管理方法を説明する。なおメモリ管理方法の詳細はmallocの実装に依存するため、実行環境によって細かなところは下記の説明と異なる部分があるので注意されたい。
mallocは未使用なヒープ領域（の一部）をメモリプールとして管理しており、メモリプールは複数のchunkと呼ばれる単位からなっている。プログラム中でmallocが実行されるたびに、管理しているchunkの中から適切なサイズのものをプログラムに返す。適切なサイズのchunkがない場合は、システムコールにより新たなchunkを確保してプログラムに返す。mallocはchunkを（サイズ毎に異なる複数の）連結リストとして管理しており、chunkをプログラムに渡す際にこの連結リストからchunkを削除し、プログラムがメモリ領域をfreeすると、freeされたchunkが連結リストに加わる。
chunkは連結リストとして管理されているので、各chunkには「次のchunk」を指定するポインタ（Windowsでは「flink」、linuxでは「fd」）や「前のchunk」を指定するポインタ（Windowsでは「blink」、linuxでは「bk」）がある。
未使用chunkと隣接するメモリ領域が解放された場合は、解放されたメモリ領域と未使用chunkとを連結 (coalesce) する事で1つの大きなchunkを作って管理する。
バッファオーバーフロー攻撃 > ヒープベースのバッファオーバーフロー > mallocのメタデータの書き換え

より高度なヒープベースバッファオーバーフロー攻撃として、mallocがメモリ管理に使うメタデータを書き換える手法がある。例えばWindows XP SP1またはそれ以前のWindowsでは、mallocしたメモリ領域をオーバーフローさせる事で、そのメモリ領域の（仮想アドレス空間で）隣りにある未使用chunkのflinkやblinkを任意のアドレスに書き換えるという攻撃手法が可能であった。flinkやblinkはcoalesceのタイミングでmallocにより参照されるので攻撃が成功する。
バッファオーバーフロー攻撃 > バッファオーバーフローの結果 > write-what-where状態

バッファオーバーフロー攻撃の結果として、write-what-where状態（"write-what-where condition"、CWE-123。任意の場所に任意の値を書き込むことができる状態）になる危険がある。
write-what-where状態になると、セキュリティポリシーのスコープ外にメモリのデータを書き込むことができる。セキュリティポリシーのスコープ外にコードを置くことで、攻撃者はほぼ確実に任意のコードを実行できるようになる。管理者権限を制御しているフラグ等が書き換えられる場合も、攻撃者は任意のコードが実行可能になる。
バッファオーバーフロー攻撃 > バッファオーバーフローの結果 > プログラムのフリーズ・クラッシュ

攻撃者は意図的にバッファオーバーフローを起こすによりプログラムをクラッシュさせたり、処理を書き換えて無限ループに追い込むことでプログラムをフリーズさせてたりする事でプログラムの可用性を侵害できる。
バッファオーバーフロー攻撃 > バッファオーバーフローの結果 > 関数ポインタの書き換え

古典的バッファオーバーフローやヒープオーバーフローなどの結果として、関数ポインタの書き換えが可能になるケースがある。攻撃者はnmコマンドを用いる事でプログラム中で用いられている様々な関数のアドレスを知る事ができるので、nmの結果を参照して攻撃に利用可能な関数に関数ポインタの値を書き換えられる。
技術的対策 > コンパイラやライブラリによる対策 > カナリア

バッファオーバーフローを検出するコードをコンパイル時に実行コードに挿入する手法がある。典型的手法としては、ローカル変数とSFPの間に、カナリア（canary）もしくはクッキーと呼ばれる領域を挿入する方法である。プログラムは実行中カナリアを監視し続け、バッファオーバーフローによりカナリアが書き換わったらプログラムを停止する。
StackGuard
Microsoft Visual C++のGSオプション
技術的対策 > コンパイラやライブラリによる対策 > 安全なライブラリへの置き換え

標準Cライブラリ等にはバッファオーバーフロー検知機能が施されていない関数が収録されているので、これを検知機能を持った関数に置き換えたライブラリを標準Cライブラリの代わりに使う事で攻撃を検知できる。例えばLibsafeは標準Cライブラリのstrcpy(*dest,*src)をより安全な関数に置き換えており、入力srcのサイズがコピー先のdestのサイズが大きいか否かを検知できる。
技術的対策 > 実行環境での対策 > Write XOR eXecute

典型的なスタックベースのバッファオーバーフロー攻撃では、本来データを格納すべき領域にシェルコードやNOP命令のような実行コードを置き、これをプログラムに実行させる事で攻撃が成立する。そこでこのような攻撃を防ぐため、データを格納すべき領域では実行不可にする、Write XOR eXecute（W {\boldsymbol {\oplus }}XもしくはW^Xと略す）という対策手法が知られている。W \oplus XのWindowsにおける実装はDEP（英: data execution prevention、データ実行防止）と呼ばれる。またDEPではSEH例外ハンドラへのポインタが上書きされないように明示的に保護を行う。
一部のUNIX（OpenBSDやmacOSなど）はW \oplus Xなどの実行保護が有効になった状態で出荷されている。それ以外のオプショナルなパッケージとしては以下のものが挙げられる。
PaX
Exec Shield
Openwall
また、プロプライエタリなアドオンとしては以下のものがある。
BufferShield
StackDefender
なお、2018年現在広く使われているx64アーキテクチャのプロセッサでは、W \oplus Xを実現する為にデータ領域である事を識別するNXビットという仕組みがハードウェアレベルでサポートされている（インテルではNXビットのことをXDビットと呼んでいるが同一のものである）。
技術的対策 > 実行環境での対策 > 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以降)、iOS(バージョン6以降)などで実装されている。またKASLRをバイパスしようとする攻撃に対抗する為の機構としてKernel page-table isolationがある。
gccとg++でコンパイルとスタック領域とヒープ領域に対してはASLRを用いるが、コード領域にASLRを用いるにはオプション「-pie」を使わねばならない。また共有ライブラリにASLRを用いるにはオプション「-fPIC」を指定する。
開発時の対策 > プログラミング言語・プログラミング環境の選択

C言語やC++以外の言語ではバッファオーバーフローが発生しないよう対策が取られているものも多く、コンパイル時にバッファオーバーフローのチェックを行ったり、実行時にバッファオーバーフローに対する警告や例外を上げたりするものもある（Ada、Eiffel、LISP、Modula-2、Smalltalk、OCaml、およびC言語から派生したCycloneやD言語など）。
Javaプラットフォームや.NET Frameworkでは全ての配列に対して境界チェックが必須とされる。ほぼすべてのインタプリタ言語ではバッファオーバーフローへの対策が行われており、エラー発生時にはその状態が明確に伝えられる。境界チェックを行うのに十分な型情報を保持しているようなプログラミング言語では、境界チェックの有効・無効を切り替えるためのオプションが提供されていることもある。
開発時の対策 > ソースコード記述時の対策

バッファオーバーフロー攻撃は主にC言語やC++を対象としたものなので、以下ではプログラミング言語としてC言語かC++を選んだ場合に対しての対策を述べる。
開発時の対策 > ソースコード記述時の対策 > 人手による対策

バッファオーバーフロー攻撃を防ぐには、領域長とデータ長を意識したプログラミングを行う事が重要である：
データをバッファに挿入する際には、データ長がバッファ長を超えない事を調べる検査ロジックをプログラムに書き加えておく
データが文字列の場合は文字列長を数え間違えないよう、文字列の終端にあるナル文字も数える
データ長に依存したループを書くときに間違ってループを回しすぎる（Off-by-oneエラー）事が無いようにする
事前にデータ長の上限がわからない場合は、バッファをmalloc等で動的に確保し、不要になったら確実にfreeする
開発時の対策 > ソースコード記述時の対策 > 安全なライブラリの使用

標準Cライブラリを使う代わりに、バッファあふれを未然に防いだりエラーとして検出してくれたりするセキュアなライブラリを使う事も重要である。このようなライブラリとして以下のようなものがある。
Managed String（Linux環境）
ISO/IEC 9899:2011 Annex K（Windows環境）
SafeStr（Linux環境、Windows環境）
"The Better String Library"
Vstr
Erwin
またBSD libcなど、Cライブラリの実装によってはstrlcpyやstrlcatといった、より安全に配慮した文字列用関数が用意されている。
開発時の対策 > 静的コード解析時における対策 > 人手による静的コード解析

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

strcpy等のバッファオーバーフローが起こりやすい関数の使用に対して警告を出してくれる関数名照合型検査ツールや、各種ソースコード検査ツールを使用してバッファオーバーフロー対策を行う。開発環境の中にはソースコード検査ツールをオプションとして備えているものもあるので、それを利用する事もできる。
またソースコードが手に入らない製品等を利用する場合は、ファジングツールでブラックボックス解析する。
発展的な攻撃 > Return-to-libc攻撃

→詳細は「Return-to-libc攻撃」を参照
既に述べたように、典型的なスタックベースのオーバーフロー攻撃では、本来データを格納すべき箇所にシェルコードやNOP命令のようなコードを置き、リターンアドレスを書き換えてこれらのコードにジャンプして、これらのコードを実行する必要があった。しかしW \oplus Xが実装された実行環境ではデータを格納すべき箇所におけるコード実行を不許可としているので、こうしたオーバーフロー攻撃を仕掛ける事はできない。
そこでW \oplus Xを回避する為に考案されたのがReturn-to-libc攻撃である。この攻撃では、リターンアドレスのジャンプ先をデータ格納箇所に書き換えるのではなく、標準Cライブラリ(libc)のような共有ライブラリ・DLLにジャンプするよう書き換える。こうしたライブラリはデータ格納箇所以外に置かれているので（W \oplus Xが実装された環境においても）実行許可がある。そこで攻撃者はライブラリ内の関数を悪用して、攻撃を仕掛ける事ができる。
実行環境がASLRを実装していれば、libc等のライブラリの仮想アドレスはランダムに変わるので、攻撃者がジャンプ先をライブラリに落ちるようリターンアドレスを書き換えるのは困難になる。
発展的な攻撃 > Return-to-Register攻撃

Return-to-Register攻撃とは「ret命令実行後にレジスタが指しているアドレスに不正な命令コードを挿入し、その上で”そのレジスタ値に実行を移す命令群が格納されているアドレス”でリターンアドレスを書き換える攻撃」のことである。
例えばレジスタAがバッファの先頭へのポインタを格納しているとすると、そのときレジスタAをオペランドにとる任意のjumpまたはcall命令が実行フローの支配権を得るのに使用できる。
発展的な攻撃 > Return-to-Register攻撃 > ret2esp攻撃

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

バッファオーバーフローがある程度公に文書化されたのは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であった。
1995年、Thomas Lopaticはそれとは独立にバッファオーバーフローを発見し、セキュリティに関するメーリングリストBugtraqへ投稿した。
1996年、エリアス・レヴィ（ハンドルネームAleph one）はオンラインマガジンPhrackで記事"Smashing the Stack for Fun and Profit"を発表した。
これはスタックベースのバッファオーバーフローを使用したエクスプロイトを手順を追って説明していく内容である。
これ以降、少なくとも2つの有名なインターネットワームがバッファオーバーフローを利用したエクスプロイトで多くのシステムに被害を与えている。2001年にはCode RedがマイクロソフトのInternet Information Services (IIS) 5.0のバッファオーバーフローを利用している。
また2003年にはSQL SlammerがMicrosoft SQL Server 2000の動作するマシンに被害を与えている。
2003年には、市販のXboxのゲームに含まれるバッファオーバーフローが利用され、無認可のソフトウェア（例えばHomebrewのゲームなど）をModチップなどのハードウェアの改造なしに動作させるのに利用された。
PlayStation 2では同じ目的のためにPS2 Independence Exploitが使用される。またWiiではHomebrewが利用されるが、これはゼルダの伝説 トワイライトプリンセスに存在するバッファオーバーフローを利用している。
ビセンテ・ルケ

| ビセンテ・ルケ |
| --- | --- |
 2022年
本名:  ヴィセンテ・カッタ・プレタ・ルケ (Vicente Catta Preta Luque)
生年月日:   (1991-11-27) 1991年11月27日（33歳）
出身地:   アメリカ合衆国 ニュージャージー州ウエストウッド
通称:  ザ・サイレント・アサシン (The Silent Assassin)
国籍:   アメリカ合衆国  ブラジル （二重国籍）
身長:  180 cm (5 ft 11 in)
体重:  77 kg (170 lb)
階級:  ウェルター級
拠点:   ブラジル ブラジリア
ランク:  ブラジリアン柔術 (茶帯) ルタ・リーブリ (紫帯)
現役期間:  2009年 -

総合格闘技記録
試合数: 34
勝利: 23
ノックアウト: 11
タップアウト: 9
判定: 3
敗戦: 10
ノックアウト: 2
タップアウト: 2
判定: 6
引き分け: 1
その他
ウェブサイト:  https://www.vicenteluque.com.br/
 総合格闘技記録 - SHERDOG
テンプレートを表示
ビセンテ・ルケ（Vicente Luque、1991年11月27日 - ）は、ブラジルの総合格闘家。アメリカ合衆国ニュージャージー州ウエストウッド出身。セラードMMA/サンフォードMMA所属。UFC世界ウェルター級ランキング14位。ビセンテ・ルーケとも表記される。
来歴

ニュージャージー州ウエストウッドで、チリ人の父親とブラジル人の母親の間に生まれた。3歳から空手を始める。6歳の時に両親が離婚、母親の母国ブラジルへ移住し、10代からムエタイ、ブラジリアン柔術を学び、2008年に総合格闘技に転向した。
来歴 > 総合格闘技

2009年6月27日、ブラジルでプロ総合格闘技デビュー。ローカル団体で7勝4敗1分の戦績を残す。
来歴 > The Ultimate Fighter

2015年4月、リアリティ番組「The Ultimate Fighter」のシーズン21にブラックジリアンズ所属で参加。
来歴 > UFC

2015年7月12日、UFC初参戦となったThe Ultimate Fighter 21 Finaleでマイケル・グレイブスと対戦し、0-3の判定負け。
2015年12月19日、UFC on FOX 17でへイダー・ハッサンと対戦し、アナコンダチョークで1Rテクニカル一本勝ち。パフォーマンス・オブ・ザ・ナイトを受賞した。
2016年9月24日、UFC Fight Night: Cyborg vs. Lansbergでヘクター・ウルビナと対戦し、右フックで1RKO勝ち。パフォーマンス・オブ・ザ・ナイトを受賞した。
2017年3月18日、UFC Fight Night: Manuwa vs. Andersonでレオン・エドワーズと対戦し、0-3の判定負け。
2019年2月17日、UFC on ESPN: Ngannou vs. Velasquezでブライアン・バーバリーナと対戦し、左膝蹴りでダウンを奪いパウンドで3RTKO勝ち。ファイト・オブ・ザ・ナイトを受賞した。
2019年8月10日、UFC Fight Night: Shevchenko vs. Carmouche 2でマイク・ペリーと対戦し、2-1の判定勝ち。ファイト・オブ・ザ・ナイトを受賞した。
2019年11月2日、UFC 244でウェルター級ランキング9位のスティーブン・トンプソンと対戦し、0-3の判定負け。敗れはしたものの、ファイト・オブ・ザ・ナイトを受賞した。
2020年8月1日、UFC Fight Night: Brunson vs. Shahbazyanでランディ・ブラウンと対戦し、右膝蹴りでダウンを奪いパウンドで2RKO勝ち。パフォーマンス・オブ・ザ・ナイトを受賞した。
2021年3月27日、UFC 260でウェルター級ランキング7位の元UFC世界ウェルター級王者タイロン・ウッドリーと対戦し、ダースチョークで1R一本勝ち。ファイト・オブ・ザ・ナイトを受賞した。
2021年8月7日、UFC 265でウェルター級ランキング5位のマイケル・キエーザと対戦し、ダースチョークで1R一本勝ち。パフォーマンス・オブ・ザ・ナイトを受賞した。
2022年4月16日、UFC on ESPN: Luque vs. Muhammad 2でウェルター級ランキング6位のベラル・ムハマッドと約5年5カ月ぶりに再戦し、0-3の5R判定負け。リベンジを許した。
2022年8月6日、UFC on ESPN: Santos vs. Hillでウェルター級ランキング13位のジェフ・ニールと対戦し、3Rに左ストレートでキャリア初となるKO負け。試合後の検査で脳出血と診断され、1年間の出場停止処分を受けた。
2023年8月12日、UFC on ESPN: Luque vs. dos Anjosで元UFC世界ライト級王者ハファエル・ドス・アンジョスと対戦し、3-0の5R判定勝ち。
2024年12月7日、UFC 310でテンバ・ゴリンボと対戦し、開始52秒にアナコンダチョークで絞め落として一本勝ち。パフォーマンス・オブ・ザ・ナイトを受賞した。