セキュリティガイド |ビットコインの恣意的盗難脆弱性の簡単な分析

この問題の脆弱性トピックは、Bitcoin の脆弱性 CVE-2010-5141 です。この脆弱性により、攻撃者が誰かのビットコインを盗む可能性があり、非常に有害です。幸いなことに、この脆弱性は悪用されておらず、すぐに修正されました。この脆弱性はビットコインのスクリプトエンジンに関連しており、パブリックチェーン開発者にとって重要な参考情報となります。現在市場に出回っているパブリックチェーンから判断すると、そのほとんどにはDAppエコシステムを構築するための仮想マシンやスクリプトエンジンが組み込まれており、これもブロックチェーンの大きなトレンドの1つです。

1. ビットコインの UTXO モデルとは何ですか?

ヒント: 脆弱性コードスニペットには UTXO 関連の知識と概念がいくつか含まれているため、脆弱性の理論的な分析を行う前にこれらの知識ポイントを理解する必要があります。すでに理解している場合は、直接スキップできます。

Ⅰ.アカウントモデルとUTXOモデル

UTXO モデルを見る前に、まず共通アカウントモデルについて説明しましょう。アカウントモデルとは何ですか?アカウントモデルのデータ構造は、単純に「アカウント => 残高」として理解でき、各アカウントは残高に対応します。たとえば、アカウント A がアカウント B に 200 を送金する場合、アカウントモデルでは、送金操作には A-200 と B+200 のみが必要です。現在、銀行システムや Ethereum などのほとんどのソフトウェアはアカウントモデルを使用しています。

しかし、ビットコインは独自に開発されたUTXOモデルを使用しています。 UTXOには「account=>balance」のようなデータ構造がないので、どうやって送金するのでしょうか？

Ⅱ.ビットコインの送金方法

A から B への転送を例にとると、UTXO でこの転送を完了するには次の操作が必要です。

1. Aの口座の残高200の出所を見つける。つまり、Aが200を受け取った取引を見つける。

2. トランザクションxを入力とし、トランザクションyを出力としてBに200を送金する場合、xとyは対応しており、xとyの送金金額は等しくなければならない。

3. トランザクションxは使用済みとしてマークされ、トランザクションyは未使用としてマークされます

2 つの取引の送金金額は等しくなければなりません。簡単に言えば、受け取った金額と同じ額だけ送金できるということです。実際その通りです。

しかし、その一部だけを他の人に譲渡する必要がある場合はどうでしょうか?答えは、その一部だけを他の人に譲渡し、残りを自分の別のアカウントに譲渡することです。

III.インターネットから 2 つの画像とテキストを引用します。

アカウントモデル

UTXOモデル

この記事では、ビットコインがなぜ UTXO モデルを採用したのかについては焦点を当てていません。 UTXO の原理を理解する必要があります。

2. ビットコインのスクリプトエンジン

Bitcoin スクリプトはチューリング完全ではありません。ビットコインは、トランザクションやその他の操作を実行するために独自に定義されたスクリプトを使用するため、ビットコインの柔軟性は限られています。マルチ署名や資金凍結などの単純な機能は実装していますが、それ以上の機能は実装していません。

ビットコインがこれを実行する理由は、セキュリティを確保するためにある程度の完全性を犠牲にするためです。 Bitcoin スクリプトの原理は、最初に一連のオペコードを定義し、次にスクリプトエンジンがスタックに基づいて各オペコードを 1 つずつ実行することです。

スタックは理解しやすいです。キューは先入れ後出しですが、スタックはその逆で先入れ先出しです。要素がスタックにプッシュされた後、最初にポップアウトされます。

Bitcoin の初期バージョンでは、標準転送 (pay-to-pubkey) トランザクションを送信するには、スクリプト署名 (scriptSig) と公開鍵検証スクリプト (scriptPubKey) が必要でした。具体的な処理フローは以下のとおりです。

まず実行するスクリプトを入力し、署名 (sig) と公開鍵 (pubKey) がスタックにプッシュされ、次にオペコード OP_CHECKSIG が署名などを検証します。検証に合格すると、スタックに true がプッシュされ、合格しないと false がスタックにプッシュされます。

3. CVE-2010-5141 脆弱性分析

上記の知識を理解した後、CVE-2010-5141 の脆弱性の分析を開始できます。作者は脆弱なバージョン 0.3.3 をダウンロードしました。ダウンロードアドレスは github のビットコインリポジトリにあり、リリースを見つけます。

script.cpp コードスニペット VerifySignature 関数:

VerifySignature 関数は各トランザクションに対して呼び出され、スクリプトを実行して署名を検証し、トランザクションが使用されたかどうかをマークするために使用されます。

まず、txFrom パラメータは前のトランザクションであり、txTo は処理中のトランザクションです。上の章で説明したUTXOモデルを理解していれば、ここでの理解は難しくありません。 EvalScript 関数が呼び出される 1125 行目に注目してください。最初のパラメータは、txin.scriptSig (署名情報を含む) + セパレータオペコード OP_CODESEPARATOR + txout.scriptPunKey (公開鍵情報、OP_CHECKSIG 命令を含む) です。これらは、EvalScript 関数によって実行されるスクリプトです。以下のパラメータは当面無視できます。 EvalScript 関数が true を返す限り、検証署名は渡されます。 EvalScript 関数はどのようにして true を返すことができますか?

まず、スタックは空にできず、スタックの最上部は bool に変換された後に true である必要があります。著者は、スタックトップが存在する必要があり、値が 0 になることはないと単純に解釈しています。

次にキーOP_CHECKSIGオペコードを見てください

(注: オペコードが多すぎるため、この記事では OP_CHECKSIG オペコードに焦点を当てます)

上記のコードは理解するのが難しくありません。 Checksig 関数は署名を検証するために呼び出され、その後 FSuccess 変数に返されます。真の場合、vchTrue (0 以外) がスタックにプッシュされ、それ以外の場合は vchFalse (0) がスタックにプッシュされます。オペコードが OP_CHECKSIG ではなく OP_CHECKSIGVERIFY の場合、vchTrue がスタックからポップされ、後続のオペコードが実行されます。

OP_CHECKSIG の通常のロジックによれば、署名検証が失敗した場合、スタックの先頭に vchFalse が残ります。スタックは空ではありませんが、スタックの一番上の値は 0 なので、false が返されます。

前のコードに戻ると、EvalScript 関数によって実行されるスクリプトは主に次の変数で構成されています。

1. txin.scriptSig

2. OP_コードセパレータ

3. txout.script公開キー

最初の署名情報は制御可能であり、2 番目の署名情報は単なる区切り文字であるため削除されます。3 番目の署名情報は、前のトランザクションからのものであるため制御できません。

最初の変数は制御可能であり、スクリプトとして実行されるため、この変数は署名情報だけでなく、オペコードにもなります。これは扱いやすいです。次に、魔法のオペコード OP_PUSHDATA4 を参照する必要があります。 Bitcoin 0.3.3 がこのオペコードをどのように処理するかを見てみましょう。

まずオペコードを取得します。オペコードの値が OP_PUSHDATA4 の値以下の場合は、すべての vchPushValues をスタックにプッシュしてから、GetOp 関数を実行します。

ソースコードを読むと、OP_PUSHDATA4 命令は 78 として定義されていることがわかります。そのため、関数が OP_PUSHDATA4 に遭遇すると、ポインターは 78+4=82 ビットに移動し、そのうち 78 ビットのデータがスタックにプッシュされます。したがって、OP_PUSHDATA4 オペコードが txin.scriptSig に挿入されている限り、後続の公開鍵情報と OP_CHECKSIG 命令は「取り込まれ」、パラメータとしてスタックにプッシュされます。ポインタが端に到達すると、最終判定が下されます。

1. スタックは空ですか?いいえ

2. スタックの一番上の要素は 0 ですか?いいえ

したがって、条件が満たされた場合、EvalScript 関数は true を返し、VerifySignature 関数も true を返します。署名の検証が回避されるため、他人のビットコインを自由に使うことができます。