Delta's web sites.

コンピュータへの不正アクセスの方法として、buffer overflow(もしくはbuffer overrun)という攻撃があります。コンピュータには「メモリ(記憶装置)」というものがありますが(HDDとか半導体とかいうのは気にしないでください)、「メモリ」にはプログラムとデータが入っています。 しかし、ここがプログラム、ここがデータという明示的な境界はありません。それはプログラマが決めます。 どういうことかというと、砂場で遊んでいる子供が、砂場が狭いと「ここまではボクの遊び場、そこからはキミの遊び場」なんて境界を作ることがありますが、「砂場」の砂の色が違ったりとか壁があったりとかはしません。第三者から見れば、どこからがボクでどこからがキミの砂場かはわからない…つまり、論理的な境界であって、物理的な壁がある訳ではないです。 ※最近はメモリ保護機能とか、単純なレベルならOSが保護してくれます。 で、buffer overflowというのは、データを溢れさせてメモリ上のプログラムを書き換えることで実現する攻撃方法です。 こういうbuffer overflowな話でよく言われる例として、プログラム言語であるC/C++の関数の「strcpy」が例によく使われます。「strcpy」は文字列Aを文字列Bにコピーするという関数です。つまり、文字列Aが10文字、文字列Bが5文字しかキャパシティが無いと、あっさりbuffer overflowが発生します。はみ出した5文字分は、メモリ上の「プログラム」がかかれている場所に行くか、「データ」の場所に行くかはわかりません(意図的にそういうことをすることはありますが…)。 ちなみに、C/C++言語にはもう少し複雑な背景があって、こういう関数が「標準化」されています。C/C++言語はVisualC++とかgccとかBorland Cとか様々な種類がありますが、「標準化」された命令はそのまま実装されています。「この命令はヤバいので乗せない」なんてことはそうそう出来ません(移植性が損なわれる)。それが、こういうセキュリティ問題をさらに根深いものにしてるとも言えるのかな。だから、未だにstrcpyはC/C++にそのまま存在します。 で、今VisualC++でプログラムをしてるけど、最近のバージョンではこんな警告が出るようになりました。

warning C4996: ‘XXXXX’: This function or variable may be unsafe. Consider using XXXXX_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.

訳)警告 C4996: ‘XXXXX’: この機能か変数が危険であるかもしれません。代わりにXXXXX_sを使用すると考えてください。 無効にするには、_CRT_SECURE_NO_WARNINGSを使用してください。

strcpyを使うと警告(エラーじゃないので、無視すればそのまま使える)がでて、strcpy_sなんてものを使うことを薦められます。ちなみに、strcpy_sはstrcpyとほとんど同じだけど、「文字数」を指定してそれを超えるとエラーになります。プログラマーが文字数を間違えたら話にならないですが、まぁそんな感じであまり意識しなくても安全なプログラムを書けるようになっています。 こういった関数を多く使うと「標準化」されたプログラムでは無くなってきます。つまり、プログラムの「移植性」が損なわれてきます。しかし、JAVAのような違うベクトルから「移植性」を重視した言語が現れてきた今日では、そもそもそういう「標準化」の意味も薄れてきているのかなぁ…と、何となく思いました。 ※っていうか、過去のプログラムを使ったら警告だらけになって一つ一つ修正しています(T_T