很多人都會擔心，我的比特幣會不會被盜，怎麼樣才能讓我的比特幣不被盜走，今天要和大家說的是比特幣漏洞CVE-2010-5141.這個漏洞可以導致攻擊者盜取任何人的比特幣，危害十分嚴重。萬幸的是該漏洞並沒有被利用過，而且修復速度極快。該漏洞與比特幣的指令碼引擎有關，對公鏈開發者具有參考意義;從當下市場上的公鏈來看，大多數都內建了虛擬機器或指令碼引擎，以此來打造DApp生態，同時也是區塊鏈的大趨勢之一。
一、比特幣當中的UTXO模型是什麼？
Tips：在漏洞程式碼片段中會涉及一些UTXO的相關知識、概念，所以對該漏洞進行理論分析之前需要先了解一下這些知識點，已經瞭解的可以直接跳過。
Ⅰ、賬戶模型與UTXO模型
我們在看UTXO模型之前先說說常見的賬戶模型，什麼是賬戶模型?賬戶模型的資料結構簡單可以理解為“賬號=>餘額”，每個賬號都對應一個餘額。舉個例子：若賬號A向賬號B轉賬200.在賬戶模型中完成這個轉賬操作只需要A-200然後B+200;目前大部分軟體都採用的是賬戶模型，比如銀行系統、以太坊等等。
而比特幣卻使用了自行研發的UTXO模型，UTXO中是沒有“賬號=>餘額”這樣的資料結構的，那怎麼進行轉賬?
Ⅱ、比特幣如何操作轉賬
以上面A向B轉賬為例，在UTXO中完成這個轉賬需要以下操作：
1. 找到A賬號下200餘額的來源，也就是意味著要找到A收款200的這筆交易x
2. 以x交易為輸入，以向B轉賬200的交易y為輸出，x與y對應且x與y的轉賬金額必須相等
3. x交易被標記為已花費，y交易被標記為未花費
兩筆交易的轉賬金額必須相等，簡單解釋就是收到多少就只能轉出多少，實際上確實是這樣。
但是又必須只給別人轉一部分的時候怎麼辦?答案是隻向他人轉一部分，然後剩下的一部分轉給自己另外一個號。
Ⅲ、引用兩張來自網路的圖文：
賬戶模型
UTXO模型
在本文當中比特幣為什麼採用UTXO模型不是重點，我們瞭解UTXO的原理即可。
二、比特幣的指令碼引擎
比特幣指令碼是非圖靈完備的。比特幣使用自行定義的一種指令碼進行交易和其他的操作，為比特幣提供有限的靈活性。實現諸如多重簽名、凍結資金等簡單功能，但更多的就不行了。
比特幣這麼做的原因是犧牲一定的完備性來保障安全性。比特幣指令碼的原理是先定義了一堆操作碼，然後指令碼引擎基於堆疊來逐個執行每個操作碼。
堆疊很好理解，佇列是先進後出，而堆疊正好相反，是先進先出，將一個元素壓入(push)堆疊後該元素會被最先彈出(pop)。
在比特幣早期的版本中傳送一筆標準轉賬(pay-to-pubkey)交易需要指令碼簽名(scriptSig)和公鑰驗證指令碼(scriptPubKey)，具體處理流程如下：
先填入要執行的指令碼(Script)，然後簽名(sig)和公鑰(pubKey)被壓入堆疊，然後操作碼OP_CHECKSIG會去驗證簽名等，若驗證透過就將true壓入堆疊，否則就將false壓入堆疊。
三、CVE-2010-5141漏洞分析
瞭解以上知識後就可以開始分析CVE-2010-5141漏洞了。筆者下載了存在漏洞的版本0.3.3.下載地址在github的bitcoin倉庫中找release.
script.cpp程式碼片段VerifySignature函式：
執行每個交易都會呼叫VerifySignature函式，該函式用於執行指令碼以及驗證簽名，然後給交易標註是否被花費。
首先txFrom引數是上一筆交易，txTo是正在處理的這筆交易，如果理解了上面的章節中講解過的UTXO模型，這裡就不難理解了。重點看1125行程式碼，呼叫了EvalScript函式，第一個引數是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)進棧;如果opcode是OP_CHECKSIGVERIFY而不是OP_CHECKSIG的話就讓vchTrue出棧，並開始執行後面的操作碼。
按照OP_CHECKSIG的正常邏輯，驗證簽名不成功的話一定會有一個vchFalse留在棧頂，雖然堆疊不為空，但是棧頂的值是0.還是會返回false。
回到之前的程式碼，EvalScript函式執行的指令碼主要由以下變數組成：
1. txin.scriptSig
2. OP_CODESEPARATOR
3. txout.scriptPubKey
第一個簽名資訊可控，第二個不用管只是一個分割符，會被刪掉，第三個不可控，因為是來自上一個交易。
第一個變數可控，而且是作為指令碼執行，所以這個變數可以不僅僅是簽名資訊，還能是opcode，這就好辦了，下面需要引用一個神奇的操作碼 OP_PUSHDATA4.我們看看比特幣0.3.3是怎麼處理這個操作碼的：
首先獲取操作碼。如果操作碼的值小於或者等於OP_PUSHDATA4的值就把vchPushValue全壓入堆疊，再跟進GetOp函式
經翻閱原始碼，發現OP_PUSHDATA4指令被定義為78.所以當函式遇到OP_PUSHDATA4時，指標會向又移78+4=82位，其中78位資料會被壓入棧，所以只要在txin.scriptSig中注入一個OP_PUSHDATA4操作碼，後面的公鑰資訊以及OP_CHECKSIG指令都會被”吃掉”並作為引數入棧，當指標走到最後時，進行最後的判斷：
1. 堆疊是否為空?不是
2. 棧頂元素是否為0?不是
於是滿足條件EvalScript函式返回true，然後VerifySignature函式也返回true，既然簽名驗證都繞過了，那別人的比特幣便可以任意花費了。
四、CVE-2010-5141漏洞修復方案
筆者下載了比特幣版本0.3.8.直接看關鍵部分程式碼
修復方案也很明確，把scriptSig和scriptPubkey分開執行，無論你scriptSig裡面有什麼也不會影響到後面的scriptPubkey執行。
寫在最後：
因為比特幣漏洞分析是從DVP第一期漏洞專題開始連載的，目前素材來自2010年，目前漏洞分析主要存在以下難點：
1. 漏洞相關資料非常少，大多數漏洞都只有一個CVE編號和簡介，不查閱大量資料無從入手。
2. 環境搭建難，難在編譯、私鏈搭建(早期的比特幣甚至沒有私鏈這個概念)等，比特幣早期的原始碼編譯需要的依賴現在很多都已經不維護並下線了。
基於這些原因，所以筆者僅做了理論研究，並未進行實踐驗證，如有錯誤之處還請指正。
另外要保證你的比特幣安全，錢包的安全非常重要，就好比你的錢，現在銀行不能為你來承擔駭客攻擊的風險，你只有自己準備一個安全的保險箱來確保你的比特幣不被偷走，這也許也是去中心化的一個特徵。
