【テクニカル・上級編】 整数オーバーフロー・アンダーフローの脆弱性とSafeMathの役割 – IoT・OT（制御システム） & ブロックチェーンセキュリティ防御ガイド

算術の深淵：EVMにおける整数オーバーフローの死線と、現代的ガードレイルの再構築

「Code is Law（コードは法なり）」という理想は、Web3の世界において時に残酷な現実を突きつける。我々リサーチチームがSCADA（監視制御システム）や産業用IoTデバイスのバイナリを解析する際、常に直面するのは「ハードウェアの物理的制約」と「ソフトウェアの論理的抽象化」の乖離だ。この乖離が最も顕著に、そして致命的に現れるのが、スマートコントラクトにおける「整数オーバーフロー・アンダーフロー」である。

かつて数千億円相当の資産を霧散させたこの脆弱性は、Solidity 0.8.0のリリースによって「過去の遺物」になったと誤解されがちだ。しかし、現場の監査現場では、ガス代最適化という名目でのuncheckedブロックの乱用や、インラインアセンブリ内での生演算による事故が後を絶たない。

本稿では、EVM（Ethereum Virtual Machine）の低レイヤにおける演算挙動から、SafeMathが果たした歴史的役割、そして現代のアーキテクトが遵守すべき防衛的実装について、泥臭い監査の視点から掘り下げていく。

—

1. EVMの「256ビット」という檻：脆弱性の根本原因

多くのプログラミング言語と同様、Solidityのuint256（符号なし256ビット整数）は、有限の器である。256ビットの最大値（$2^{256} – 1$）に対して1を加算すれば、桁上がりしたビットは行き場を失い、値は0へと回帰する。これがオーバーフローだ。逆に、0から1を引けば、補数表現の反転により最大値へと跳ね上がる。これがアンダーフローである。

なぜこれがIoT/OTエンジニアにとって既視感があるのか

PLC（Programmable Logic Controller）や組み込みデバイスのC言語実装において、16ビットや32ビットのカウンタがラップアラウンドし、制御ループが暴走するケースと構造は全く同じだ。しかし、ブロックチェーンにおけるこの「計算ミス」は、物理的な機械の破壊ではなく、経済的なプロトコルの崩壊を直結させる。

悪名高きBEC（BeautyChain）トークンの事例（CVE-2018-10299）

このインシデントでは、複数のアドレスにトークンを一括送信する関数の「合計金額の計算」に脆弱性があった。

// 典型的な脆弱なコード例（Solidity 0.8.0以前の設計思想）
function batchTransfer(address[] _receivers, uint256 _value) public whenNotPaused returns (bool) {
    uint cnt = _receivers.length;
    // 【脆弱性】cnt * _value の計算でオーバーフローが発生する
    // 例: _value が極大値の場合、乗算結果が極小（例: 0付近）になり、残高チェックをすり抜ける
    uint256 amount = uint256(cnt) * _value; 
    
    require(cnt > 0 && cnt <= 20);
    require(_value > 0 && balances[msg.sender] >= amount); // 不当に小さいamountでチェックを通過

    balances[msg.sender] = balances[msg.sender] - amount;
    for (uint i = 0; i < cnt; i++) {
        balances[_receivers[i]] = balances[_receivers[i]] + _value; // 攻撃対象に莫大なトークンが発行される
    }
    return true;
}

この一行の乗算が、攻撃者に実質的に無限のトークンを生成する権限を与えてしまった。EVMレベルで見れば、単なるMUL（乗算）命令の実行に過ぎないが、その「意味論（セマンティクス）」が崩壊した瞬間である。

—

2. SafeMath：コミュニティによる暫定的な「盾」

Solidity 0.8.0以前、我々ホワイトハッカーがコード監査で真っ先に探したのは、OpenZeppelinが提供するSafeMathライブラリの有無だった。SafeMathは、演算を行う前にassertやrevertを用いて、結果が論理的に正しい範囲に収まっているかを愚直にチェックする。

SafeMathの内部構造（論理的ガードレイル）

SafeMathは、低レイヤの演算をラップし、以下のような条件分岐を挿入する。

// SafeMath.add の概念的実装
function add(uint256 a, uint256 b) internal pure returns (uint256) {
    uint256 c = a + b;
    // 加算後の値が元の値より小さくなることは、オーバーフロー以外にありえない
    require(c >= a, "SafeMath: addition overflow");
    return c;
}

この「チェック付き演算」を全ての算術箇所に適用することで、開発者はオーバーフローの恐怖から解放された。しかし、代償として、各演算ごとに条件分岐のJUMP命令とスタック操作が発生し、ガス消費量が増大するという課題も抱えていた。

—

3. Solidity 0.8.0の革命と、新たな盲点：uncheckedの誘惑

2020年12月、Solidity 0.8.0がリリースされ、コンパイラレベルでオーバーフロー・アンダーフローのチェックがデフォルトで組み込まれた。これにより、SafeMathを明示的にインポートする必要はなくなった。

しかし、ここからが現代のセキュリティリサーチャーが警鐘を鳴らすポイントだ。

意図的な制約解除：unchecked

Solidity 0.8.xでは、ガス代を節約するために、オーバーフローが絶対に起きないと確信できる箇所をuncheckedブロックで囲むことができる。

// Solidity 0.8.x 以降のパターン
function optimizedIncrement(uint256[] memory data) public pure {
    for (uint256 i = 0; i < data.length; ) {
        // ループカウンタのインクリメントは通常オーバーフローしないため、
        // ガス代節約のために unchecked を使うケースが多い
        unchecked { i++; }
    }
}

ここが盲点だ。
複雑な金融アルゴリズム（DeFiのイールド計算やAMMの価格カーブ）において、開発者が「ここは絶対にオーバーフローしない」と過信し、uncheckedを適用した箇所に脆弱性が潜むケースが激増している。

また、IoTゲートウェイから送られてくるセンサーデータの集計処理をスマートコントラクトで行う際、パケット構造の解析ミスやデータ型の不一致から、unchecked内で予期せぬ挙動が発生し、システム全体の整合性が破壊されるリスクがある。

—

4. 監査の最前線：防御層の設計指針

最高峰のセキュリティアーキテクトとして、我々が提唱する「多層防御」の観点を以下にまとめる。

① インラインアセンブリ（Yul）の排除、あるいは徹底監視

EVMアセンブリ（Yul）で記述された演算は、Solidity 0.8.xであってもチェックの対象外となる。

function lowLevelAdd(uint256 a, uint256 b) public pure returns (uint256 result) {
    assembly {
        // ここでの加算はオーバーフローしても revert しない
        result := add(a, b)
    }
}

アセンブリを使用する場合は、手動でオーバーフローチェックを実装しなければならない。これはSCADAシステムのファームウェアをバイナリレベルでパッチするのと同等の慎重さが求められる作業だ。

② 耐量子暗号と署名スキームへの影響

将来的な耐量子暗号（PQC）への移行期において、署名検証アルゴリズムをSolidityで実装する際、巨大な素数体上での演算が必要になる。この際の剰余演算（addmod, mulmod）の扱いや、中間値のオーバーフロー制御は、標準的なuint256の挙動を超えた深い理解が必要となる。

③ 生成AI時代のガードレイル

昨今、GitHub Copilot等の生成AIがコードを書く機会が増えている。しかし、AIはしばしば「古いSolidityの書き方（SafeMathなし）」と「新しい書き方」を混同する。テックリードは、CI/CDパイプラインにおいて、静的解析ツール（SlitherやMythril）を強制し、uncheckedブロックの使用箇所に対して「なぜ必要か」という数理的証明をコメントで求めるべきだ。

—

結論：技術的知性と泥臭い検証の融合

整数オーバーフローの歴史は、コンピュータサイエンスの歴史そのものである。Web3のスマートコントラクトであれ、IoTの制御システムであれ、我々が守るべきはビットの羅列ではなく、その背後にある信頼の連鎖だ。

Solidity 0.8.0は強力な武器だが、それを扱うのは人間であり、人間は常に「効率」という甘い誘惑に負ける。uncheckedという小さな穴から、数億ドルの資産が流出する。その「たった1ビットの反転」を防ぐために、我々セキュリティスペシャリストは今日もコードの深淵を覗き続ける。

技術の最先端に立つ者こそ、最も基礎的な算術の挙動に対して謙虚であるべきだ。それが、堅牢なデジタルアーキテクチャを築く唯一の道である。

スポンサーリンク

コメント

タイトルとURLをコピーしました