整数オーバーフローと型混同の脆弱性原理

なぜ「計算ミス」がメモリ破壊になるのか

メモリ破壊の入口は、必ずしも書き込みループそのものではありません。多くの実世界の脆弱性は、書き込み量や確保サイズを決める「整数計算」が誤ることから始まります。C/C++ の固定幅整数（int は典型的に 32 ビット、size_t はポインタ幅）は、表現範囲を超えると例外を出さず**静かに折り返す（wrap around）**ためです。

この静かな折り返しが危険なのは、サイズ計算の結果が、その直後の境界チェックや malloc の引数として使われるからです。チェックを通った「正しそうな小さい値」が、実際には攻撃者が意図した過少値である――この食い違いが、確保した領域を超える書き込みへとつながります。型混同はこれと並ぶもう一つの根因で、こちらはメモリの「解釈」を誤らせることで同種の破壊に至ります。本記事はメモリ破壊攻撃の原理で扱った「溢れた後どう乗っ取るか」の**手前にある「なぜ溢れるか」**を掘り下げます。

桁あふれ（unsigned wrap）が境界チェックを無効化する

符号なし整数の演算は 2 の n 乗を法とするモジュラ演算です。32 ビット unsigned なら、結果は常に 2^32 で割った余りに丸められます。つまり大きな値どうしの加算・乗算が、ラップして小さな値に化けることがあります。

典型は「ヘッダで指定された個数 × 要素サイズ」をそのまま確保サイズにする実装です。

/* count は攻撃者が制御するヘッダ由来の値（uint32_t） */
uint32_t count = read_u32(input);
size_t size = count * sizeof(record_t);   /* ← ここで乗算がラップし得る */
record_t *buf = malloc(size);             /* 過少サイズで確保される */
for (uint32_t i = 0; i < count; i++)
    buf[i] = parse_record(input);         /* count 回書く → 領域外書き込み */

sizeof(record_t) が 16、count が 0x10000001（約 2.7 億）なら、本来必要なのは約 4.3 GB です。ところが 32 ビット幅で計算すると 0x10000001 * 16 = 0x100000010 が 2^32 を超え、下位 32 ビットだけが残って size は 16 になります。malloc(16) は成功し、その後ループは count 回（約 2.7 億回）書き込むため、確保領域を遥かに超えてヒープを破壊します。これがサイズ計算ミス由来のヒープオーバーフローの核心です。

ここで重要なのは、if (size > LIMIT) のようなチェックを置いても無意味な点です。チェックが見るのは既にラップした後の小さい size であり、巨大な実需要量ではないからです。検査が「実際の意図」ではなく「壊れた計算結果」を見ているため、防御として機能しません。

符号の取り違え（signed/unsigned 混同）

桁あふれと並ぶ古典が符号の取り違えです。C の整数昇格・変換規則では、符号付きと符号なしを比較すると符号付き側が符号なしに変換されます。負数は 2 の補数のビット列のまま巨大な正数として解釈されます。

/* len は long（符号付き）、攻撃者が負数を送り込めるとする */
int recv_into(char *dst, long len) {
    if (len > BUFSZ) return -1;        /* 上限チェックのつもり */
    memcpy(dst, src, len);             /* memcpy の第3引数は size_t（符号なし） */
    return 0;
}

len に -1 を渡すと、len > BUFSZ の比較では -1 は小さいのでチェックを通過します。ところが memcpy の第 3 引数は size_t（符号なし）で、-1 は SIZE_MAX（64 ビットなら約 1844 京）に化けます。結果、memcpy は事実上「メモリ全域をコピーせよ」と命じられ、即座に巨大な領域外アクセスを起こします。下限チェック（len < 0 の拒否）を入れ忘れた上限だけのチェックは、こうして容易に破られます。

型混同（type confusion）がメモリ破壊に至る原理

型混同は、整数あふれとは別系統ですが、同じく「メモリの誤った扱い」という根を持ちます。あるメモリ領域を、確保・初期化されたときの型 A とは異なる型 B として解釈・操作する欠陥です。型 A と型 B でフィールドの並びやサイズが異なれば、型 B のつもりで読み書きしたバイトが、型 A の別の意味を持つ領域（特にポインタ）を踏みます。

最も危険なのは、ポリモーフィズムを持つ C++ オブジェクトの先頭にあるvtable ポインタを誤読・上書きさせる経路です。

本来の型 A（Widget）の先頭          攻撃者が B として上書きした像
  +------------------+             +------------------+
  | vtable ポインタ   | ← 正規     | 攻撃者が選んだ値   | ← 偽 vtable を指す
  +------------------+             +------------------+
  | フィールド ...    |             | データ ...        |
  +------------------+             +------------------+
obj->virtual_method() は          仮想呼び出しが攻撃者の
[vtable+offset] を間接ジャンプ      用意した関数ポインタへ飛ぶ

C++ の仮想メソッド呼び出しは「オブジェクト先頭の vtable ポインタを読み → そのテーブルの所定オフセットにある関数ポインタへ間接ジャンプ」という間接呼び出しです。型混同で先頭バイト列を攻撃者が制御できれば、vtable ポインタを偽テーブルへ向け、仮想呼び出し1回で制御を奪えます。これはメモリ破壊攻撃の原理で見た「制御フローがメモリ上のデータとして存在する」性質の、別の表れ方です。

型混同の発生源は多岐にわたります。

• 不正なキャスト：reinterpret_cast や C スタイルキャストで基底型を別系統の派生型へ強制変換する。実行時型情報（RTTI）を確認しない static_cast の誤用も同様。
• union の取り違え：あるメンバで書き、別の型のメンバで読む。タグ（どのメンバが有効か）を検査しない実装で起きる。
• 逐次化／逆シリアライズ：受信データの型タグを信用し、想定外の型として復元する。JavaScript エンジンや言語ランタイムで頻出し、JIT の型推測（type speculation）が裏切られる経路が典型。

整数あふれと型混同の関係を整理する

両者は独立に見えますが、「信頼できない入力が、サイズや解釈を決める値に流れ込む」という共通構造を持ちます。違いは、壊すのが「数値計算」か「型の解釈」かです。

緩和の発想はメモリ破壊攻撃の原理と地続きで、DEP/NX・ASLR・カナリアは最終段の悪用を高コスト化します。ただし整数あふれ・型混同はより上流の論理欠陥なので、配置のランダム化では「溢れること自体」を防げません。根は計算と型の扱いにあります。

実務での向き合い方

根治は、**サイズ計算と型の扱いを「信頼できない入力に対して安全」**に設計することです。最終段の緩和に頼り切らない姿勢が要点になります。

• 計算を安全にする：確保サイズは size_t で統一し、加算・乗算の前にオーバーフローを検査する。calloc(count, size)（内部で乗算検査）や __builtin_mul_overflow を使い、生の count * size を書かない。負長が入り得る経路は < 0 を明示的に弾く。
• 型を安全にする：危険なキャスト（reinterpret_cast、C スタイルキャスト）を避け、多態の境界では RTTI（dynamic_cast）やタグ付き union（std::variant）で型を検証する。逆シリアライズは受信側でスキーマと型タグを必ず検査する。
• 言語・ツールで網を張る：Rust など整数オーバーフローをデバッグ時に panic させ、型安全をコンパイル時に担保する言語へ移す。C/C++ では UBSan（-fsanitize=integer,bounds）や ASan、fuzzing で開発段階に検出する。

これらは設計と実装で「壊れた値が生まれないこと」を狙うもので、運用面では最小権限の原則でプロセス権限を絞り、万一の破壊が成立しても被害範囲を抑える多層構えが効きます。検出の確からしさはペネトレーションテストによる実測と組み合わせて担保するのが実務の定石です。