スマートコントラクトの脆弱性とその攻撃メカニズム

概要

整数オーバーフローは、数値型変数（特に符号なし整数 `uint`）がその型で表現できる最大値を超えて増加した際に、値がゼロ（または小さい値）に戻ってしまう現象です。逆に、整数アンダーフローは、ゼロ未満に減少しようとした際に、非常に大きな値になってしまう現象です。

Solidityのバージョン0.8.0以降では、デフォルトでオーバーフロー/アンダーフローのチェックが行われ、発生した場合はエラー（Revert）となるため、この脆弱性のリスクは大幅に低減しました。しかし、それ以前のバージョンや、`unchecked` ブロックを使用している場合は依然として注意が必要です。

攻撃メカニズム

攻撃者は、意図的に演算結果がオーバーフローまたはアンダーフローするように、関数の引数を操作します。

• オーバーフローの例： トークン残高が `uint8`（最大値255）で管理されている場合、残高250のユーザーがさらに10トークンを受け取ると、計算結果が260となりオーバーフローを起こし、残高が4（260 % 256）になってしまう可能性があります。
• アンダーフローの例： ユーザーの残高が10のときに、20を引き出すような操作が（チェックなしに）許可された場合、`10 – 20` の結果がアンダーフローを起こし、非常に大きな値（例: `uint256` の最大値に近い値）になってしまう可能性があります。これにより、攻撃者は大量のトークンを不正に得ることができてしまいます。

事例

2018年4月、いくつかのERC20トークン（例: BeautyChain (BEC)）で整数オーバーフローの脆弱性が発見されました。`batchTransfer` 関数のような、複数のアドレスにトークンを一度に送金する機能において、送金総額を計算する際にオーバーフローが発生し、攻撃者が意図的に大量のトークンを生成（または転送）できるようになってしまいました。これにより、該当トークンの価格が暴落し、取引所での取引が停止される事態となりました。

対策

• Solidity 0.8.0以降の使用： 最も簡単で効果的な対策です。デフォルトでチェックが行われます。
• SafeMathライブラリの使用（Solidity 0.8.0未満）： OpenZeppelinなどが提供する `SafeMath` ライブラリを使用することで、安全な算術演算（加算、減算、乗算、除算）を行うことができます。演算結果がオーバーフロー/アンダーフローする場合、エラーを発生させます。
• `unchecked` ブロックの慎重な使用： Solidity 0.8.0以降でも、ガスの最適化などの目的で `unchecked` ブロックを使用することがありますが、その範囲内ではオーバーフロー/アンダーフローのチェックが行われません。使用する場合は、演算結果が安全な範囲に収まることをコードレベルで保証する必要があります。

// Solidity 0.8.0 未満で SafeMath を使用する例
import "@openzeppelin/contracts/utils/math/SafeMath.sol";
contract SafeMathExample { using SafeMath for uint256; uint256 public value; function safeAdd(uint256 _add) public { value = value.add(_add); // SafeMath の add 関数を使用 } function safeSub(uint256 _sub) public { value = value.sub(_sub); // SafeMath の sub 関数を使用 }
}
// Solidity 0.8.0 以降の unchecked ブロックの例
contract UncheckedExample { uint256 public counter; function incrementUnchecked() public { // このブロック内ではオーバーフローチェックが行われない unchecked { counter++; } }
}

概要

ブロックチェーン上のトランザクションは、処理される（ブロックに取り込まれる）前に、メモリプール（mempool）と呼ばれる待機場所で公開されています。攻撃者はこのメモリプールを監視し、利益を得られるような未確認トランザクションを見つけると、それよりも高いガス価格を設定して自身のトランザクションを先に処理させることで、利益を横取りする攻撃です。

攻撃メカニズム

分散型取引所（DEX）での取引が典型的な例です。

1. ユーザーAが、あるトークンを大きな数量で購入するトランザクションを送信します（これにより価格が上昇すると予想される）。
2. 攻撃者はメモリプールでこのトランザクションを検知します。
3. 攻撃者は、ユーザーAのトランザクションが処理される直前に、同じトークンを購入するトランザクションを、より高いガス価格で送信します。
4. マイナーはガス価格の高い攻撃者のトランザクションを先に処理します。攻撃者はトークンを安値で購入します。
5. 次にユーザーAのトランザクションが処理され、トークン価格が上昇します。
6. 攻撃者は、価格が上昇した後に保有しているトークンを売却し、差額を利益として得ます。

DEXだけでなく、特定の情報を先に知ることで有利になるようなオンチェーンゲームやオークションなども標的になり得ます。

対策

フロントランニングを完全に防ぐことは困難ですが、影響を軽減するための対策はあります。

• コミット・リビール・スキーム（Commit-Reveal Scheme）： ユーザーはまず、トランザクションの内容（例: 購入価格、数量）のハッシュ値だけをコミット（公開）します。後のブロックで、実際のトランザクション内容をリビール（公開）します。これにより、コミット段階では攻撃者はトランザクションの詳細を知ることができません。
• 潜水艦送信（Submarine Sends）： トランザクションをメモリプールに公開せず、信頼できるマイナーに直接送信するなどの方法ですが、一般的ではありません。
• ガス価格の工夫（限定的）： ガス価格を調整することである程度の対策は可能ですが、確実ではありません。
• スリッページ許容範囲の設定： DEXなどでは、ユーザーが許容する価格変動（スリッページ）の範囲を設定できるようにし、想定外の価格での約定を防ぎます。
• バッチ処理： 複数のトランザクションをまとめて処理することで、個々のトランザクションの順序の重要性を低下させます。