スマートコントラクトにおけるリエントラント攻撃とは何ですか?

リエントラント攻撃について

1. リエントラント攻撃は、最初の実行が完了する前に、悪意のあるコントラクトが別のコントラクトの脆弱な機能を繰り返しコールバックするときに発生します。

2. このエクスプロイトは、状態の変更が完了する前に制御が外部アドレスに転送される、イーサリアム スマート コントラクトの外部呼び出しメカニズムを利用します。

3. 攻撃者は、ターゲットの出金または転送ロジックの再帰的呼び出しをトリガーするフォールバックまたは受信関数を含むコントラクトを展開します。

4. Ethereum はシングルスレッドの同期方式で呼び出しを実行し、デフォルトではアトミックな状態の更新を強制しないため、残高やフラグはコールバック ウィンドウ中に変更されないままになる可能性があります。

5. その結果、適切なチェックなしで資金が同じ残高から複数回流出する可能性があり、システムの意図された経済的不変条件に違反します。

有名な歴史的例: DAO ハック

1. 2016 年 6 月、DAO として知られる分散型自律組織が、当時の価値で 5,000 万ドル以上に相当する約360 万 ETHで侵害されました。

2. この脆弱性は、提案が可決された後にユーザーが自分の株式を引き出すことを可能にする分割機能に存在していましたが、資金を送金した後に寄稿者の残高を更新していました。

3. 攻撃者は、残高更新が行われる前に分割関数を再帰的に呼び出すフォールバック関数を含むコントラクトをデプロイしました。

4. 各再帰呼び出しにより元の残高値が読み取られ、同じ割り当て金額から繰り返し引き出すことが可能になります。

5. この事件はイーサリアム ブロックチェーンのハード フォークを引き起こし、その結果イーサリアムとイーサリアム クラシックが 2 つの別個のチェーンとして誕生しました。

リエントラントを可能にする技術的条件

1. 信頼できないアドレスへの外部呼び出しは、残高の更新やアクセス フラグの切り替えなどの重大な状態変更の前に行う必要があります。

2. コントラクトは、再入保護を強制することなく、所有権または資格を反映する変更可能なストレージ変数に依存する必要があります。

3. ロックされたブール値または再入可能修飾子の使用など、ミューテックス パターンが存在しない場合、ネストされた呼び出しコンテキスト全体でエントリ ポイントが保護されないままになります。

4. transfer()やsend()のようなより安全な代替手段の代わりにcall()のような低レベルの呼び出しを使用すると、ガス給付制限の欠如と自動復帰動作によりリスクが増加します。

5. 古いライブラリまたは未監査のライブラリから継承したコントラクトにより、継承された再入可能サーフェスを持つ関数が意図せず公開される可能性があります。

現在展開されている緩和戦略

1. Checks-Effects-Interactions パターンでは、条件の検証、内部状態の更新、その後でのみ外部呼び出しの実行が義務付けられます。

2. OpenZeppelin のReentrancyGuardなどのリエントランシー ガードは、ロックされたブール値を使用して、アクティブな実行中の関数の再入力を防ぎます。

3. raw call()の代わりにtransfer()またはsend()を使用すると、2300 ガスの制限が適用され、フォールバック関数はさらなる再入可能な呼び出しを含む複雑なロジックを実行できなくなります。

4. Slither や MythX などの静的分析ツールは、開発および CI パイプライン中に潜在的なリエントランシー ベクトルを検出します。

5. Certora や KEVM などの形式的検証フレームワークは、ネストされた外部呼び出しを含む、任意の呼び出しシーケンスの下でコントラクトの不変条件を検証します。

よくある質問

Q1.リエントランシー攻撃はイーサリアム以外のブロックチェーンでも発生する可能性がありますか? A1.はい。 BNB チェーン、ポリゴン、アービトラムを含む EVM 互換チェーンは、コントラクトが同じ欠陥のある対話パターンを複製する場合、同様に影響を受けます。特定の条件下での Solana のプログラム間呼び出しなど、同様の外部呼び出しセマンティクスを持つ非 EVM チェーンも同様のリスクに直面します。

Q2. require() ステートメントの使用は再入を防ぐのに十分ですか? A2.いいえ。Require ステートメントは前提条件を検証しますが、再エントリをブロックしません。これらは状態が変化する前に動作し、外部呼び出しが発生すると後続のコールバックを制限できません。

Q3.プロキシベースのアップグレード可能な契約では、追加の再入可能サーフェスが導入されますか? A3.はい。実装コントラクトに再入保護が欠如しており、プロキシが通話の深さを傍受または検証せずに通話を転送する場合、アップグレード可能なパターンが既存の脆弱性を継承または増幅する可能性があります。

Q4.悪意のある契約がなくても、フラッシュ ローンはリエントラントを引き起こす可能性がありますか? A4.はい。フラッシュ ローンを利用した攻撃は、dYdX、Harvest Finance、BurgerSwap に対するエクスプロイトに見られるように、価格オラクル操作とリエントランシーを組み合わせて流動性プールや融資プロトコルを枯渇させることが多く、すべてクリティカル パス内の無防備な外部呼び出しに依存しています。