用意した領域より大きいデータを書き込むと、隣に置かれていた別の情報まで上書きされます。厄介なのは、その隣に「処理が終わったら次にどこへ戻るか」の情報が置かれている場合があること。そこを書き換えられると、攻撃者の用意した命令へ処理が飛びます。
先に押さえる
原因はほぼ1つ、受け取る側が長さを確かめていないことです。長さを見ずに複写する処理が残っていると、外から与える文字列の長さで領域の外まで書けてしまいます。だから根本対策も1つ、境界を検査する。それ以外の対策は、成立を難しくする補助です。
何が起きるか
1はみ出した分が隣を壊す
用意した領域たとえば64文字ぶん
↓長さを見ずに、200文字を書き込む
隣の領域別の変数や、戻り先の情報が上書きされるここが乗っ取りの入口
↓戻り先が攻撃者の指す場所に変わる
意図しない命令の実行そのプログラムの権限で動く
似た型に解放したはずの領域を使い続ける不具合があります。手放した後に別の用途で使い回された領域を、古い手掛かりで触ってしまうもので、中身を攻撃者に差し替えられると同じ結末になります。どちらも「メモリの扱いを誤る」系統です。
つまずきポイント
「実行できないようにする」「配置を毎回変える」といった成立しにくくする対策は有効ですが、脆弱性そのものは残ります。設問では「これらを入れれば安全か」と聞かれ、答えはいいえ。回避される手口があり、根本対策は長さの検査や安全な関数への置き換えです。暫定と恒久を混ぜないのがここでも要点になります。
対策の層
根本（アプリ側）
- 入力の長さを検査してから複写する
- 長さを取る安全な関数を使う
- 境界を自動で守る言語・仕組みを選ぶ
成立を難しくする（環境側）
- データ領域の実行を禁止する
- 配置を毎回変える（狙う場所を当てにくくする）
- 戻り先の破壊を検知して落とす
見抜きどころ
組込み機器の設問でよく出ます。理由は資源が限られていて保護の仕組みを入れにくい、更新が届きにくいから。答案では「入力長を検査していないこと」を原因として明示し、対策はアプリの修正が本命、環境側の緩和は補助と分けて書きます。「不正な入力を防ぐ」だけでは弱く、何を検査するかまで書くと点になります。