本期漏洞專題是比特幣漏洞CVE-2010-5141，這個漏洞可以導致攻擊者盜取任何人的比特幣，危害十分嚴重。萬幸的是該漏洞并沒有被利用過，而且修復速度極快。該漏洞與比特幣的腳本引擎有關，對公鏈開發(fā)者具有參考意義；從當下市場上的公鏈來看，大多數(shù)都內置了虛擬機或腳本引擎，以此來打造DApp生態(tài)，同時也是區(qū)塊鏈的大趨勢之一。

一、比特幣當中的UTXO模型是什么？

Tips：在漏洞代碼片段中會涉及一些UTXO的相關知識、概念，所以對該漏洞進行理論分析之前需要先了解一下這些知識點，已經了解的可以直接跳過。

Ⅰ、賬戶模型與UTXO模型

我們在看UTXO模型之前先說說常見的賬戶模型，什么是賬戶模型？賬戶模型的數(shù)據(jù)結構簡單可以理解為“賬號=》余額”，每個賬號都對應一個余額。舉個例子：若賬號A向賬號B轉賬200，在賬戶模型中完成這個轉賬操作只需要A-200然后B+200；目前大部分軟件都采用的是賬戶模型，比如銀行系統(tǒng)、以太坊等等。

而比特幣卻使用了自行研發(fā)的UTXO模型，UTXO中是沒有“賬號=》余額”這樣的數(shù)據(jù)結構的，那怎么進行轉賬？

Ⅱ、比特幣如何操作轉賬

以上面A向B轉賬為例，在UTXO中完成這個轉賬需要以下操作：

1. 找到A賬號下200余額的來源，也就是意味著要找到A收款200的這筆交易x

2. 以x交易為輸入，以向B轉賬200的交易y為輸出，x與y對應且x與y的轉賬金額必須相等

3. x交易被標記為已花費，y交易被標記為未花費

兩筆交易的轉賬金額必須相等，簡單解釋就是收到多少就只能轉出多少，實際上確實是這樣。

但是又必須只給別人轉一部分的時候怎么辦？答案是只向他人轉一部分，然后剩下的一部分轉給自己另外一個號。

Ⅲ、引用兩張來自網(wǎng)絡的圖文：

在本文當中比特幣為什么采用UTXO模型不是重點，我們了解UTXO的原理即可。

二、比特幣的腳本引擎

比特幣腳本是非圖靈完備的。比特幣使用自行定義的一種腳本進行交易和其他的操作，為比特幣提供有限的靈活性。實現(xiàn)諸如多重簽名、凍結資金等簡單功能，但更多的就不行了。

比特幣這么做的原因是犧牲一定的完備性來保障安全性。比特幣腳本的原理是先定義了一堆操作碼，然后腳本引擎基于堆棧來逐個執(zhí)行每個操作碼。

堆棧很好理解，隊列是先進后出，而堆棧正好相反，是先進先出，將一個元素壓入（push）堆棧后該元素會被最先彈出（pop）。

在比特幣早期的版本中發(fā)送一筆標準轉賬（pay-to-pubkey）交易需要腳本簽名（scriptSig）和公鑰驗證腳本（scriptPubKey），具體處理流程如下：

先填入要執(zhí)行的腳本（Script），然后簽名（sig）和公鑰（pubKey）被壓入堆棧，然后操作碼OP_CHECKSIG會去驗證簽名等，若驗證通過就將true壓入堆棧，否則就將false壓入堆棧。

三、CVE-2010-5141漏洞分析

了解以上知識后就可以開始分析CVE-2010-5141漏洞了。筆者下載了存在漏洞的版本0.3.3，下載地址在github的bitcoin倉庫中找release.

script.cpp代碼片段VerifySignature函數(shù)：

執(zhí)行每個交易都會調用VerifySignature函數(shù)，該函數(shù)用于執(zhí)行腳本以及驗證簽名，然后給交易標注是否被花費。

首先txFrom參數(shù)是上一筆交易，txTo是正在處理的這筆交易，如果理解了上面的章節(jié)中講解過的UTXO模型，這里就不難理解了。重點看1125行代碼，調用了EvalScript函數(shù)，第一個參數(shù)是txin.scriptSig（包含簽名信息）+分隔操作碼OP_CODESEPARATOR+ txout.scriptPunKey（包含公鑰信息、OP_CHECKSIG指令），這些就是EvalScript函數(shù)要執(zhí)行的腳本，后面的參數(shù)可以暫時不用管，只要EvalScript函數(shù)返回true那么這筆驗證簽名就通過了。EvalScript函數(shù)如何才能返回true？

首先堆棧不能是空的，然后棧頂強轉bool后必須是true。筆者簡單解讀為必須要有棧頂而且值不能是0。

然后再看關鍵的OP_CHECKSIG操作碼

（注：由于操作碼太多，本文針對OP_CHECKSIG操作碼）

上面代碼不難理解，調用Checksig函數(shù)來驗證簽名，然后返回給FSuccess變量，如果為真就壓一個vchTrue（非0）進棧，否則就壓一個vchFalse（0）進棧；如果opcode是OP_CHECKSIGVERIFY而不是OP_CHECKSIG的話就讓vchTrue出棧，并開始執(zhí)行后面的操作碼。

按照OP_CHECKSIG的正常邏輯，驗證簽名不成功的話一定會有一個vchFalse留在棧頂，雖然堆棧不為空，但是棧頂?shù)闹凳?，還是會返回false。

回到之前的代碼，EvalScript函數(shù)執(zhí)行的腳本主要由以下變量組成：

1. txin.scriptSig

2. OP_CODESEPARATOR

3. txout.scriptPubKey

第一個簽名信息可控，第二個不用管只是一個分割符，會被刪掉，第三個不可控，因為是來自上一個交易。

第一個變量可控，而且是作為腳本執(zhí)行，所以這個變量可以不僅僅是簽名信息，還能是opcode，這就好辦了，下面需要引用一個神奇的操作碼 OP_PUSHDATA4，我們看看比特幣0.3.3是怎么處理這個操作碼的：

首先獲取操作碼。如果操作碼的值小于或者等于OP_PUSHDATA4的值就把vchPushValue全壓入堆棧，再跟進GetOp函數(shù)

經翻閱源碼，發(fā)現(xiàn)OP_PUSHDATA4指令被定義為78，所以當函數(shù)遇到OP_PUSHDATA4時，指針會向又移78+4=82位，其中78位數(shù)據(jù)會被壓入棧，所以只要在txin.scriptSig中注入一個OP_PUSHDATA4操作碼，后面的公鑰信息以及OP_CHECKSIG指令都會被”吃掉”并作為參數(shù)入棧，當指針走到最后時，進行最后的判斷：

1. 堆棧是否為空？不是

2. 棧頂元素是否為0？不是

于是滿足條件EvalScript函數(shù)返回true，然后VerifySignature函數(shù)也返回true，既然簽名驗證都繞過了，那別人的比特幣便可以任意花費了。

四、CVE-2010-5141漏洞修復方案

筆者下載了比特幣版本0.3.8，直接看關鍵部分代碼

修復方案也很明確，把scriptSig和scriptPubkey分開執(zhí)行，無論你scriptSig里面有什么也不會影響到后面的scriptPubkey執(zhí)行。

寫在最后：

因為比特幣漏洞分析是從DVP第一期漏洞專題開始連載的，目前素材來自2010年，目前漏洞分析主要存在以下難點：

1. 漏洞相關資料非常少，大多數(shù)漏洞都只有一個CVE編號和簡介，不查閱大量資料無從入手。

2. 環(huán)境搭建難，難在編譯、私鏈搭建（早期的比特幣甚至沒有私鏈這個概念）等，比特幣早期的源碼編譯需要的依賴現(xiàn)在很多都已經不維護并下線了。

基于這些原因，所以筆者僅做了理論研究，并未進行實踐驗證，如有錯誤之處還請指正。