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

Solidity 0.8.0の衝撃：なぜ私たちは「暗黙のオーバーフロー」を忘れてはならないのか

スマートコントラクトのセキュリティ監査を行っていると、いまだに「古いコードベースの遺物」と遭遇する。Solidity 0.8.0がリリースされてからというもの、コンパイラが標準で算術演算のオーバーフロー・アンダーフローを検知し、即座にトランザクションをリバート（Revert）してくれるようになった。

「もうSafeMathをインポートする必要はない。ハッカーの常套手段だった整数脆弱性は過去のものになった」――そう安易に考えていないだろうか。

現場のオフェンシブ・セキュリティの視点から言えば、それは致命的な誤認だ。コンパイラの進化は防衛側の大きな武器だが、低レイヤのメモリ挙動、EVM（Ethereum Virtual Machine）の仕様、そして開発者が陥る「uncheckedの罠」を理解していなければ、現代のDeFiプロトコルも一瞬で崩壊する。本稿では、Solidityの算術演算の変遷を辿りながら、攻撃者がどこを突き、私たちアーキテクトがどう守るべきかを深掘りする。

—

1. 根本原因の解剖：EVMにおける数値表現とオーバーフロー

そもそも、なぜブロックチェーンの世界では整数オーバーフローがこれほどまでに脅威となったのか。

EVMは基本的に256ビット（32バイト）のワードサイズでデータを処理する。uint256は、$0$ から $2^{256} – 1$ までの数値を格納できるが、もし $2^{256} – 1$ を超える演算（加算など）を行うと、上位のビットは切り捨てられ、下位のビットのみが残る。これがオーバーフローだ。逆に、0から1を引けば、type(uint256).max（最大値）にラップアラウンド（アンダーフロー）する。

Solidity 0.8.0以前、開発者はこれを自衛するためにOpenZeppelinのSafeMathライブラリを挟む必要があった。

// 【危険なレガシーコードの例】Solidity 0.8.0未満
pragma solidity ^0.6.0;

contract VulnerableBank {
    mapping(address => uint256) public balances;

    function deposit() public payable {
        // もし残高が限界値付近であればオーバーフローを起こし得る
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint256 _amount) public {
        // アンダーフロー対策がなければ、残高以上の引き出しが可能になるバグの温床
        require(balances[msg.sender] >= _amount, "Insufficient balance");
        balances[msg.sender] -= _amount;
        (bool sent, ) = msg.sender.call{value: _amount}("");
        require(sent, "Failed to send Ether");
    }
}

このコードでは、もしrequireのロジックが不十分であったり、複雑なトークンのミント・バーンロジックが絡んだりすると、攻撃者は無限に近いトークンを生成し、プールをドレイン（資金抜き取り）することが可能だった。数々の著名なDeFiハックが、この単純な数値の巻き戻しによって引き起こされたのである。

—

2. Solidity 0.8.0以降の防御機構と、その「盲点」

Solidity 0.8.0以降、すべての算術演算はデフォルトでオーバーフロー／アンダーフローのチェック（Panic error 0x11の発生によるリバート）を行うようになった。これは素晴らしい改善だが、実務の現場では新たなリスクを生んでいる。

uncheckedブロックという名のパンドラの箱

ガス最適化（Gas Optimization）のプレッシャーにさらされた開発者は、しばしばunchecked { ... }ブロックを乱用する。例えば、ループカウンタのインクリメントなど、オーバーフローが絶対に起きないことが自明な箇所で使用するのは正しい。しかし、ビジネスロジックの複雑な計算や、プロトコル間の数値のやり取りでこれを適用した瞬間、脆弱性が復活する。

以下は、uncheckedの誤用による脆弱なコントラクトの典型例だ。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract UncheckedRiskExample {
    mapping(address => uint256) public userCredits;

    // ガス代をケチるためにuncheckedを使用したが...
    function subtractCredit(address _user, uint256 _amount) public {
        unchecked {
            // ここでオーバーフローチェックが無効化される
            // _amountがuserCredits[_user]より大きい場合、アンダーフローが発生して巨大な数値になる
            userCredits[_user] -= _amount; 
        }
    }
}

チーフホワイトハッカーとして監査を行う際、私はソースコード内のuncheckedキーワードを最優先でgrepする。開発者が「ガス効率」という魔力に魅入られ、安全装置を自ら外している箇所こそ、ブラックハットが最初に狙う急所だからだ。

—

3. 高度なセキュリティアーキテクチャ設計：多層防御の構築

スマートコントラクトにおける算術演算の安全性を担保するためには、コンパイラの機能に依存するだけでなく、堅牢なアーキテクチャを設計する必要がある。

A. 明示的な境界値検証（FuzzingとInvariants）

単なるユニットテストでは、極端な入力値（Edge Cases）によるオーバーフローや、予期せぬ状態遷移を見落とす。FoundryやEchidnaを用いたファジングテスト（Fuzz Testing）をCI/CDパイプラインに組み込み、不変条件（Invariants）を常に検証させることが必須である。

// Foundryを用いたインバリアントテストの例
function invariant_total_supply_matches() public {
    // トークンの総供給量が、各保有者の残高の総和と常に一致しているかを検証
    assertEq(token.totalSupply(), token.sumOfAllBalances());
}

B. 型の適切な選択とキャスティング

Solidityでは、uint8からuint256まで様々なビット幅の整数を使える。例えば、小さな数値を扱うためにuint8を使用し、それを別の計算に組み込むと、意図せぬ暗黙の型変換やオーバーフローを引き起こす原因になる。極力uint256に統一し、どうしても小さな型が必要な場合は、OpenZeppelinのSafeCastライブラリ等を用いて明示的な範囲チェックを挟むべきだ。

import "@openzeppelin/contracts/utils/math/SafeCast.sol";

// SafeCastを使った安全な型変換の例
using SafeCast for uint256;

uint256 largeValue = 1000;
uint8 smallValue = largeValue.toUint8(); // 255を超える場合は自動でリバートする

—

4. セキュリティスペシャリストからの提言

ブロックチェーンのセキュリティにおいて、「これで完全に安全」という状態は存在しない。Solidity 0.8.0の組み込みチェックは強力だが、それは言語仕様レベルの防御壁の1つに過ぎない。

プロトコルの設計段階から、以下の鉄則をチーム全体で共有してほしい。

1. uncheckedは「論理的にオーバーフローが絶対に起きないことの数学的証明」ができない限り使うな。 ガス最適化は、セキュリティ監査の最終段階でプロファイリングを行ってからでも遅くない。
2. 外部オラクルや他プロトコルからの入力値を信用するな。 自コントラクトが安全でも、インプットされる数値自体が不正であれば、計算結果は破綻する。
3. 静的解析ツールとファジァーを自動化せよ。 SlitherやMythril、Foundryを駆使し、人間の眼では見逃す低レイヤの脆弱性を機械的に排除し続けること。

脆弱性との戦いはイタチごっこだ。しかし、EVMの挙動を深く理解し、コードの隅々にまで目を光らせるアーキテクチャさえあれば、攻撃者の侵入経路を確実に断つことができる。泥臭く、しかし洗練されたコードを書くこと――それこそが、真のWeb3セキュリティの極意である。