書式文字列攻撃

書式文字列攻撃（しょしきもじれつこうげき、）は、1999年ごろ発見された（それまでは無害と考えられていた）セキュリティホールを利用した攻撃のクラスである。書式文字列攻撃は、プログラムをクラッシュさせたり、不正なコードを実行させたりできる。
概要.
問題は、codice_1 などの書式指定のあるC言語の関数で、ユーザーが入力した文字列をそのまま書式文字列として利用する場合に発生する。悪意のあるユーザーが %s や %x といった書式トークンを使い、スタックやその他のメモリ位置の内容をデータとして出力させることができる。また、%n トークンを使って任意のアドレス位置に任意のデータを書き込ませたりする。
これらのテクニックを組み合わせて、ライブラリ関数のアドレスを書き換えたり、コールスタック上のリターンアドレスを書き換えて不正なコードを実行させる。書式文字列を工夫することで書式文字列自体が変換対象の引数となるようにでき、書式文字列の先頭に %n で上書きされるアドレスを含めておくと、不正なコードを指定したアドレスに書き込める。
それまで書式のバグがあっても危険はないと考えられていたため、この種の脆弱性を持つツールが多数存在することがわかった。MITRE's CVE project のリストによれば、約 150 もの脆弱なプログラムがある。
この種のバグは、プログラマがユーザーの入力した文字列を表示しようとした場合に現れやすい。プログラマが codice_2 と書くべきところを codice_3 と書いてしまう場合である。この場合、codice_4 が書式文字列として解釈され、変換文字が含まれているとそれを書式として翻訳しようとする。codice_2 であれば、単に入力された文字列を表示するだけである。
この問題は、C言語の引数の解釈で型を意識しないために発生する。特に codice_6 でも使われている codice_7 機構はサブルーチンに任意個の引数を渡せる。codice_6 では第一引数である書式文字列の内容によって必要な引数の個数が決まり、それによってコールスタックから引数を pop して使用する。
このバグは1990年にウィスコンシン大学で行われた評価（各種APIにでたらめな引数を与えてシステムクラッシュなどの問題が発生しないかを調査）で最初に見つかった（Miller, Fredriksen, So 1990 参照）。彼らはこれを "interaction effects" と呼び、cshの評価でそれを見つけている。このような不具合の評価手法は後に他者によって体系化され、ファジングと呼ばれることになる。
書式文字列のバグで攻撃される可能性は Tymm Twillman が ProFTPD デーモンのセキュリティ検査中に発見した。その検査で、snprintf にユーザーが入力したデータがそのまま書式文字列として使われているのが見つかった。さらなる評価の結果、このバグを利用してセキュリティを破ることが可能と判明した。この結果を 1999年9月にBugtraqメーリングリストに新たな脆弱性報告としてポストした。しかし、これが重大な問題であると認識されるまで数ヶ月を要することになった。
危険な書式文字列を防ぐ方法.
多くのコンパイラは書式文字列を静的にチェックし、問題がある場合には警告を発する。
GNUコンパイラコレクションでは、適当なコンパイラフラグとして、codice_9,codice_10, codice_11, codice_12, codice_13, codice_14 がある。