T28 · Smart Contract Security

現実の問題

20行の金庫コントラクトです。預け入れ、引き出します。

function withdraw() external {
    uint256 amount = balances[msg.sender];
    require(amount > 0, "nothing to withdraw");

    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok, "transfer failed");

    balances[msg.sender] = 0;
}

一行ずつ読んでみます。

第一行、この人の残高を読みます。正しいです。 第二行、残高がなければ拒否します。正しいです。 第三行、その金額を送ります。正しいです。 第四行、送金が失敗したら全体を戻します。正しいです。 第五行、残高をゼロにします。正しいです。

五行とも、単独で見れば完全に正しいです。コンパイル警告はゼロ、単体テストは全て成功し、分岐網羅率も100%です。

公開の翌日、金庫が空になりました。一人分ではなく、全員の資金が盗まれました。

取引の呼び出し履歴を見ると異常があります。一つの取引で withdraw に数十回入り、毎回成功して同額を送っています。開始したアカウントが最初に預けたのは、ごく少額でした。

もはや「どの行を間違えたか」という問題ではありません。間違った行はありません。

問うべきは、五行の間に、逐行で読んだとき見えていなかった何が起きたのか？ です。

思考実験

このコードを銀行窓口の業務に置き換えます。

引き出しに来たあなたに、行員は三つの作業をします。

1. 帳簿を開き、あなたの残高を見る
2. 引き出しから同額の現金を数え、渡す
3. 帳簿の残高を消す

自然な順序に見え、ほとんどの場合は問題ありません。

条件を加えます。第二段階で渡す瞬間、あなたはすぐ次の要求を出せます。行員は第三段階に戻る前に、新しい要求を処理しなければなりません。

するとこうなります。

帳簿を見る：残高100      →  100を渡す
その瞬間に次の要求       →  帳簿を見る：まだ100（消していない！）
                        →  また100を渡す
さらに次の要求           →  帳簿はまだ100
                        →  また100を渡す
...
引き出しが空になり、ようやく帳簿の100を消す

帳簿を消したのは一回、現金を渡したのは数十回です。

行員の計算は一度も間違っていません。 毎回帳簿を確認し、その通りの金額を渡しました。間違いは一つだけです。

「現金は出たが、記帳していない」瞬間に、次の要求の割り込みを許しました。

これが最初の五行の問題の全てです。第三行の msg.sender.call は送金だけでなく、実行権を相手に渡します。その瞬間に相手のコードが動きますが、帳簿には古い値が残っています。

もう一つの思考実験は、この章の後半に対応します。

オフィスの正面入口では警備員が身分証を確認し、一度も間違えず、入居者は安心しています。しかし設計時に「従業員しか知らない」と判断した側面入口には、警備員を置いていません。

確認は一度も間違えなくても、侵入されました。 安全性を決めるのは確認の厳しさではなく、確認を迂回する経路があるかです。

二つを合わせると、この章の全体になります。

脆弱性は一行のコードではなく、二行間の順序と、守られていない経路にあります。

あなたが決める

最初の金庫を修正します。一か所だけ先に変えるなら、どこにしますか？

結果を観察する

四つの修正を比べます。

第一の結論です。

順序は根治、ロックは保険。両方が必要です。

ロックを加えても盲点があるため、順序を無視できません。順序が正しくても、後の変更で誰かが戻してしまう可能性があり、そのときロックが救うため、ロックを省けません。

第二の結論が、この章の中心です。

外部アドレスへの呼び出しは必ず実行権を渡します。渡す前に、状態の整合を取っておく必要があります。

これはnative tokenの送金だけには限りません。実行権を渡す場所を全て列挙すると、想像以上にあります。T7、T9、T12 で予告してきた一覧が、ここで完成します。

第三の結論は二つ目の思考実験からです。

安全性は確認の厳しさではなく、確認を迂回する経路の有無で決まります。

コントラクトの監査では、逐行で読むだけでなく、各経路について、誰が入り口を守るかを問います。

モデルを作る

実行権を渡す場所

全て列挙します。印刷してモニターに貼っておきたい表です。

最後の行が、この表の要点です。

全てのアドレス引数は、コントラクトかもしれません。

T9 のNFT標準で説明した受取確認のcallbackは、取り出せないアドレスへの送付を防ぐものですが、送付中に受取人へ実行権を渡すことも意味します。例で詳しく見ます。

// 一見、普通のmint関数
function mint(uint256 qty) external payable {
    require(qty <= MAX_PER_TX, "too many");
    require(minted[msg.sender] + qty <= MAX_PER_WALLET, "wallet limit");
    require(msg.value == qty * PRICE, "wrong value");

    for (uint256 i = 0; i < qty; i++) {
        _safeMint(msg.sender, nextId++);   // この行で受取人をcallbackする
    }

    minted[msg.sender] += qty;             // callbackの後に数を更新する
}

受取人はcallback内で mint に再入します。minted[msg.sender] は古い値のままで、wallet上限の確認は機能しません。各行は正しくても、順序が間違っています。

同じ構造の四つの形態

多くの人は第一しか知りませんが、実際の事故は第三でよく起きます。

第三は近年多い事故なので詳しく扱います。被害を受けるのは、自分ではなく統合先であることが多いです。

// 総資産を総share数で割って価格を出す金庫
function pricePerShare() external view returns (uint256) {
    return (address(this).balance * 1e18) / totalShares;
}

function redeem(uint256 shares) external nonReentrant {
    uint256 amount = (address(this).balance * shares) / totalShares;
    sharesOf[msg.sender] -= shares;

    (bool ok, ) = msg.sender.call{value: amount}("");   // ここで実行権を渡す
    require(ok, "transfer failed");

    totalShares -= shares;      // 分母はこの後に更新する
}

redeem はロックされているので再入できません。しかし、その call の間はこうなります。

分子（コントラクト残高）：既に減った
分母（totalShares）：まだ減っていない
→ pricePerShareは真の値より低い数を返す

この間、外部コントラクトは金庫に触らず、pricePerShare をoracleに使う別の融資プロトコルを呼びます。そのプロトコルは低い価格を読み、T21 のoracle操作の経路が成立します。

教訓は三つです。

1. view 関数にはロックがなく、ロックを持つこともできません。 読む状態の整合を常に保つことが唯一の防御です。
2. CEIの状態には、外部が読む全ての派生値が含まれます。その関数で明示的に変更する変数だけではありません。
3. 統合先は、読み取る瞬間の値が中間状態ではないかを問う必要があります。 前章の「上流を信頼できなければ、自分の側に防御を置く」という規則の別の適用です。

CEI：三文字の順序

Checks        全ての確認と引数検証を先に行う
Effects       コントラクトの状態を「既に実行された」状態にする
Interactions  最後に外部とやり取りする

比較します。

T19 の例外では、実際のAMMはflash swapのため先に送り、後で不変条件を検証します。CEI違反ではなく、Effectsを「やり取りの後の不変条件検証」に置き換えています。 成立するには、不変条件を明確に書き、やり取りが戻った後、一つずつ検証できなければなりません。

やり取り後に整合を確認する方式は、不変条件を書ける場合だけ認められます。書けなければCEIの順序に従います。

権限の境界

前節は順序、ここは境界の問題です。二つで脆弱性の大半を占めます。

第五は二つのコントラクトをまたぐため最も見つけにくく、片方だけ監査しても分かりません。

// 金庫：strategyコントラクトだけ信頼する
function pull(uint256 amount) external {
    require(msg.sender == strategy, "only strategy");
    token.transfer(strategy, amount);
}

// strategy：誰でも起動できるrebalancing関数
function rebalance(address to, uint256 amount) external {   // 確認が一切ない
    vault.pull(amount);
    token.transfer(to, amount);
}

金庫の確認は正しく、strategyは信頼されたアドレスです。しかしstrategyは、その信頼を無条件で全員に渡します。

権限の監査はmodifierを読むだけでなく、誰が何段階で関数へ到達するかの図を描きます。 一段でも「誰でも」があれば、経路全体が「誰でも」です。

最後の実践規則です。

既定で拒否します。 外部関数を追加するときは権限が必要と仮定し、公開できる理由を示します。逆にはしません。

精度と丸めの方向

この種の問題は、攻撃技術を必要とせず、あなたより丁寧に計算する人がいれば成立します。

整数除算は常に切り捨てます。これはbugではありません。誤差がどちら側に落ちるかが問題です。

そのまま使える規則です。

丸めの誤差は全て、利用者ではなくプロトコルに有利な側に落とします。

表にするとこうです。

もう一つ、乗算を先、除算を後にします。 逆にすると精度を失ってから誤差を増幅する、よくある自滅になります。

二つが組み合わさる典型例、最初の預金者の問題を見ます。

初期状態：totalShares = 0、金庫は空

1. 最初の人が1 weiを預ける
   初回は通常1:1  →  1 shareを得る、totalShares = 1

2. 同じ人が【depositを通さず】10000 tokenを直接送る
   残高 = 10000e18 + 1、totalSharesは依然1

3. 次の人が10000 tokenを預ける
   share = 10000e18 * totalShares / 残高
        = 10000e18 * 1 / (10000e18 + 1)
        = 0          ← 整数除算の切り捨て

4. この人は0 shareを得る。10000 tokenは金庫資産になるが、
   全share（1）は最初の人が持っている

三つの条件が同時に必要で、個別に見ると問題なさそうです。

- shareは「資産×総share数÷総資産」で計算し、切り捨てる
- 総資産は直接残高を読むので、直接送金で汚染できる
- 極小の初回入金を認め、totalSharesが1になれる

対応する三つの防御は、通常組み合わせます。

1. 内部記帳：総資産は残高ではなく、自ら管理する変数を使い、直接送られた資金は算入しません。
2. 仮想shareと仮想資産：分子と分母へ固定offsetを加え、0 shareになる操作を経済的に割に合わなくします。
3. dead share：初期化時に引き出せないアドレスへshareをmintし、totalShares が危険な小ささにならないようにします。

さらに、算出shareが0ならrevertします。 一行でこの問題の最後の段階を止めます。

upgradeのリスク

T8 のproxyの三つの原則を適用し、第四を加えます。

第一、storage layoutは末尾に追加するだけです。 挿入、型の変更、並べ替え、削除は禁止です。

reviewだけでは守れず、CIで守ります。各版のstorage layoutをファイルとしてrepositoryへ保存し、upgrade時にscriptで比較して追加だけを認めます。完全に自動化できる確認なので、省く理由はありません。

第二、proxy自身の変数は疑似ランダムな固定slotに置きます。slot 0から宣言すると実装と衝突します。

第三、実装自身も直接callできるアドレスです。 constructorで初期化済みとし、他人の再初期化を禁止します。自身を破壊できる経路も置きません。

第四、upgradeはコードだけでなく、操作自体も監査対象です。 次を答えます。

- 誰がupgradeできるか。一人、multisig、ガバナンス投票か？
- timelockはあるか、長さは？
- eventを出し、外部monitoringに見えるか？
- 新版初期化の手順はあり、守られているか？
- upgrade失敗後にrollbackできるか？

第24章 の言葉を繰り返します。timelockのないupgrade可能なコントラクトは、upgrade鍵の持ち主へ全資金を渡すことと同じです。 どれほどコードがきれいでも、これを守らなければ前の努力は無駄になります。

不変条件：全体をまとめる

四種類の問題を見ました。形は違いますが、共通点があります。

全て、常に成立すべき命題が、ある瞬間に成立しない問題です。

これを不変条件と呼びます。専門的に見える文章を書くことではなく、次に価値があります。

不変条件は、機械が繰り返し検証できる安全性の表現です。

「この関数は大丈夫だと思う」は検証できません。「残高は全利用者残高の合計以上」は、何百万ものランダムな操作列を生成し、各操作の後に検証できます。

次の段階でそれを行います。この章から、状態を持つコントラクトを書くたび、機能より先に不変条件を書く習慣を付けます。 書き方と自動検証はT30です。

何と呼ぶか

実践

基準1：少額を預けたアカウントが、預入額以上を回収することをテストで証明する
基準2：順序修正後、同じテストが成功から失敗に変わる
基準3：ロックと順序修正の防御対象と盲点を説明する

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

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

    function deposit() external payable {
        require(msg.value > 0, "zero deposit");
        balances[msg.sender] += msg.value;
    }

    function withdraw() external {
        uint256 amount = balances[msg.sender];
        require(amount > 0, "nothing to withdraw");

        // この行でmsg.senderへ実行権を渡す
        (bool ok, ) = msg.sender.call{value: amount}("");
        require(ok, "transfer failed");

        // 戻ってきた時点では、上の処理に何度も再入した可能性がある
        balances[msg.sender] = 0;
    }

    function totalAssets() external view returns (uint256) {
        return address(this).balance;
    }
}

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

interface IVault {
    function deposit() external payable;
    function withdraw() external;
}

// test fixture：ローカルだけで脆弱性の存在を証明する
contract ReentrancyProbe {
    IVault  public immutable vault;
    uint256 public unit;

    constructor(address v) {
        vault = IVault(v);
    }

    function start() external payable {
        unit = msg.value;
        vault.deposit{value: msg.value}();
        vault.withdraw();
    }

    // 金庫からの送金でここが起動し、金庫の帳簿はまだゼロではない
    receive() external payable {
        if (address(vault).balance >= unit) {
            vault.withdraw();
        }
    }
}

- 金庫のtotalAssets()が0またはほぼ0に下がる
- probeの回収額が最初の小額より明らかに多い

function withdraw() external {
    uint256 amount = balances[msg.sender];
    require(amount > 0, "nothing to withdraw");

    balances[msg.sender] = 0;                     // 記帳を先にする
    (bool ok, ) = msg.sender.call{value: amount}("");   // 外部操作を後にする
    require(ok, "transfer failed");
}

AI Lab

第一段階：
私のコントラクトです（実践の金庫、読み取り経路を持つshareコントラクト、
自作の権限伝達問題を一つ含む二コントラクト構造を渡す）。
全ての安全性問題を見つけ、それぞれ次を示してください。
- 具体的な関数と行
- 起動の前提条件とcall順序
- 結果
- 修正方法
監査を推奨する、再入に注意など、具体性のない発言は不要です。

第二段階：
各報告を【現在のコードで失敗する】テストにしてください。
書けない場合は確信できていないので、その旨を記してください。

第三段階：
意図して少なくとも二か所の問題を残し、伝えていません。
読み取り経路と、コントラクト間の権限伝達です。
この二種類を特に探し、もう一度監査してください。

実例

変数を一つ変える

持ち帰る問い

章末チェック