上周,bitcoin core 0.16.3 版本客戶端的突然發(fā)布,以及開發(fā)者敦促大家盡快升級一事,令比特幣世界的人們感到了驚訝。表面上的原因,在于0.14-0.16.2版本客戶端中存在一個拒絕服務 (DoS) 向量需要被修補。到后來,我們才發(fā)現(xiàn),在0.15-0.16.2版本core客戶端中的另一個漏洞,可能會引起比特幣的超發(fā)問題。
在這篇文章中,作者試圖說明:到底發(fā)生了什么?潛在的危險是什么?以及如果有人利用這個漏洞,還將會發(fā)生什么?
雙重支付的兩種方式
在我們接觸實際的漏洞之前,我們需要解釋一些東西。我們首先需要定義一下雙重支付,因為這個漏洞就可以用于雙重支付。
所謂雙重支付的情況,就比如說愛麗絲(Alice)向鮑勃(Bob)支付了一筆幣,然后她又把相同的幣再一次支付給了查利(Charlie),愛麗絲基本上試圖進行兩次支付,其中的一筆她知道會被拒回。當然,當我們考慮支付時,愛麗絲的某些賬戶通過寫這兩次支付被透支了。這很接近比特幣的工作原理,但并不是十分準確。
比特幣并不是基于帳戶模型的,而是基于未花費交易輸出(UTXO)。一筆交易的輸出基本包含了一個地址以及數量。一旦輸出被使用了,它就無法再次被花費。試想一下一個UTXO(作為一筆發(fā)送給你的幣),它可以是任意數量的,比如說0.413 BTC。
比特幣的雙重支付意味著一筆幣(UTXO)被花費了兩次。通常,這意味著愛麗絲將她的0.413 BTC發(fā)送給了鮑勃,然后她又把同一筆比特幣又發(fā)送給了查利。
比特幣的解決方法是,其中一筆交易會納入一個區(qū)塊,由此來決定實際誰得到了報酬。如果兩筆交易不知何故都傳遞到了多個區(qū)塊,那么后面發(fā)生的區(qū)塊,就會被軟件給拒絕掉。如果兩筆交易都在同一個區(qū)塊當中,那么這個區(qū)塊也會遭到軟件的拒絕。
基本上,比特幣軟件會檢測到雙重支付行為,如果有雙重支付行為的發(fā)生,則應該拒絕掉相應的區(qū)塊。
然而,在兩筆不同的交易中發(fā)送同一個UTXO,并不是唯一的雙花方法。實際還存在著同一UTXO在同一交易進行雙重支付的病態(tài)情況。在這種情況下,愛麗絲向鮑勃發(fā)送同一筆幣兩次。所以,愛麗絲實際支付的是0.413 BTC,但鮑勃收到的卻是0.826 BTC。這顯然不是一個有效的交易,因為只有一筆價值0.413 BTC的UTXO 是被發(fā)送的。這就相當于,愛麗絲用同一10美元向鮑勃發(fā)送了兩次,而鮑勃收到的則是20美元。
定義漏洞
因此,總結一下我們所定義的兩種類型的雙重支付嘗試:
使用兩筆或更多的交易,來花費相同的UTXO;
使用一筆交易花費同一UTXO多次;
結果表明,Bitcoin Core 軟件正確地處理了第一個問題,而第二個問題,正是我們要關心的。任何人都可以像這樣構造出一筆雙花交易,但要讓節(jié)點接受這種交易,又是另一回事了。
目前有兩種方法可以讓交易被納入一個區(qū)塊當中: A. 支付足夠的費用,將交易廣播到網絡上,那么礦工會負責把交易納入區(qū)塊當中;
B. 作為一名礦工,把交易納入一個區(qū)塊;
(A) 除了創(chuàng)建交易,并將其廣播到網絡上的節(jié)點之外,你不需要做太多的工作。 (B) 需要你找到足夠的工作量證明。這也是這次漏洞的關鍵。
(A) 不是一個可能的攻擊向量,因為這些交易會立即被標記為無效的,網絡上的節(jié)點會拒絕它們。沒有礦工們的合作,這種交易就無法進入礦工們的記憶庫,因為它們不會得到傳播。
(B)是漏洞顯現(xiàn)的唯一情況。換句話說,想要利用這個漏洞,你就需要工作量證明,或者說足夠的礦機設備和電力。
為了明確起見,雙花交易有4種情況需要處理:
1A?— 多筆 mempool交易花費了同一UTXO ;
1B?— 多筆區(qū)塊交易花費了同一UTXO ;
2A?— 單筆mempool交易花費了同一UTXO多次;
2B?— 單筆區(qū)塊交易花費了同一UTXO多次;
該漏洞有兩種表現(xiàn)形式。在0.14.x版本客戶端中,存在著一個拒絕服務(DoS)的漏洞,而在0.15.x - 0.16.2版本的客戶端,則存在一個超發(fā)漏洞。接下來,我們會分別分析它們。
拒絕服務攻擊
故事始于2009年的Bitcoin 0.1版本客戶端,這一版本的代碼通過拒絕案例1B和案例2B(檢查區(qū)塊沒有雙重支付)來強制達成共識。
你可以看到“檢查沖突”的注釋,其代碼負責檢查每個輸入沒有被花費。“將輸出標記為已使用”注釋下面的代碼,標記了UTXO的使用。如果任何UTXO的花費超過一次,則會導致錯誤。
在2011年,PR 443被合并到了比特幣代碼庫。這一改變是為了處理通過mempool (上面的情況2A)傳輸單筆交易雙重支付的情況。這個合并請求注釋的目的非常明確:
“而且,沒有具有重復輸入的交易會被納入區(qū)塊當中。..。..幾個星期前,有人嘗試過了,但這些交易并沒有被納入區(qū)塊。我假設某個地方存在了一個檢查關,它會阻止這些重復交易進入區(qū)塊,雖然我沒有對這個問題進行任何挖掘。這實際上是為了防止這種明顯無效的交易得到中繼。”
實際的代碼更改,或多或少與上面的ConnectInputs 中的“檢查沖突”注釋下的代碼執(zhí)行了相同的操作,但位于的是不同的位置。代碼更改是在CheckTransaction 中運行的,其負責了所有上述的4種情況(1A, 1B, 2A, 2B)。因此,我們在區(qū)塊雙重支付共識代碼中有了一些冗余,正如案例1B和2B都被檢查了兩次,其中一次檢查是在CheckTransaction,另一次則發(fā)生在ConnectInputs。
到了2013年,PR 2224被納入了比特幣軟件。這一改變的目的是區(qū)分共識錯誤(例如雙重支付)和系統(tǒng)錯誤(例如磁盤空間耗盡)之間的差別,正如PR注釋中所表明的那樣:
“它引入了CValidationState,它會存儲關于區(qū)塊的元數據,或者正在執(zhí)行的交易驗證數據。它被用于區(qū)分驗證錯誤(例如,未能滿足網絡規(guī)則)和運行時錯誤(比如磁盤空間的不足),從前這些可能會產生混淆,因磁盤空間用完會導致區(qū)塊被標記為無效。此外,CValidationState還承擔了跟蹤 DoS級別的角色(因此它不需要存儲于交易或區(qū)塊當中。..)”
實際的相關代碼更改如下:
在那個時候,ConnectInputs已經被模塊化成多個方法,并且這個函數成為了檢查雙重支付的函數。這里的關鍵改變是,曾經的error被改為了 assert
assert在C++中是做什么的?它會完全中止程序。程序員為什么要在這里停止程序?這就是Pull請求的目的所在。下面就是那個時候的代碼片段:
它會像以前一樣處理案例1B和2B。函數名則從ConnectInputs更改為ConnectBlock,但檢查案例1B和2B的冗余性仍然在PR 443中保留。正如我們已經看到的,UpdateCoins做了第二次雙重支付檢查。其中CheckBlock通過調用CheckTransaction進行了第一次雙重支付檢查:
由于這是第二次檢查相同的內容,所以要讓UpdateCoins的雙花檢查失敗的唯一方法,就是存在某種UTXO數據庫或交易存儲損壞。事實上,這似乎是改成assert的原因。因為CheckBlock通過CheckTransaction在UpdateCoins之前已經進行了檢查,我們已知道某筆交易并不是雙花交易。因此,PR 2224正確地推測到,UpdateCoins中的這個狀態(tài)必然是一個系統(tǒng)錯誤,而不是一個共識錯誤。在這種情況下,為了防止進一步的數據損壞,正確的做法就是停止程序。
到了2017年,PR 9049作為Bitcoin 0.14的一部分被引入比特幣網絡。隨著隔離見證(Segwit)的納入,它是加快區(qū)塊驗證時間的諸多更改的其中之一,其代碼更改實際是非常少的:
你可以看到布爾函數 fCheckDuplicateInputs被添加了進去,用于加快區(qū)塊檢查。我們將在下面看到,這是一個被認為是冗余的檢查。不幸的是, UpdateCoins中的代碼在PR 2224中被更改為系統(tǒng)損壞檢查,而不是共識檢查。到了0.14.0版本客戶端,其代碼進行了更多的模塊化更改,而assert也發(fā)生了一些改變:
曾經是作為一個冗余檢查,現(xiàn)在卻成了負責區(qū)塊單筆交易雙重支付檢查(案例2B),并負責停止程序。從技術上來說,它仍然是強制執(zhí)行共識規(guī)則。只是在中止程序問題上,它表現(xiàn)地非常糟糕。
PR 9049是如何獲得通過的? Greg Maxwell 給了我IRC上的聊天記錄。
長話短說,開發(fā)者們在討論PR 9049時,傾向于認為區(qū)塊級單筆交易雙重支付(案例2B)會在PR 443處遭到檢查,而沒有考慮PR 2224。這使得開發(fā)者們并沒有密切關注PR 9049;
總而言之:
1、在2011年引入用于防止雙重支付交易中繼(案例2A)的 PR 443,實際產生了一個副作用,即對區(qū)塊的雙重支付共識規(guī)則檢查創(chuàng)造了冗余校驗(案例1B和 2B)。
2、PR 2224是在2013年引入的,作為一種副作用,將(1)中用于區(qū)塊驗證的代碼,從冗余升級到了共識層;
3、PR 9049是在2017年被引入的,并且它跳過了(1)中用于單個區(qū)塊單筆交易雙重支付(案例1B)檢查的代碼。開發(fā)人員錯誤地認為代碼是多余的,因為他們沒有考慮到(2)。事實上,這種改變跳過了共識的關鍵部分。
公平地講,這些事的匯合導致了這次漏洞。
DoS漏洞的嚴重性
這意味著 0.14.x 版本的Core軟件可能會因為一個奇怪的區(qū)塊而崩潰。而要讓軟件崩潰,攻擊者需要做的事是:
1.創(chuàng)建一筆花費兩次同一UTXO的交易;
2.通過足夠的工作量證明,將(1)中的交易納入一個比特幣區(qū)塊;
3.將這個區(qū)塊廣播到0.14.x版本軟件的節(jié)點;
(1) 和 (3) 的成本并不高,而步驟(2)的最小成本為12.5 BTC。
如果你認為從博弈論的角度來看,分裂網絡并不是那么好,那么利用這個漏洞的動機就相當低了。充其量,作為攻擊者,你花費了12.5 BTC將部分全節(jié)點給搞崩潰。由于不可能從分裂網絡中獲利,攻擊者無法輕易地補償自己的攻擊成本。
如果這是唯一的漏洞,那么攻擊者可能給很多人帶來一些不便,但這不會是持續(xù)的,因為這些被攻擊的節(jié)點可以簡單地重啟,并連接到其它誠實節(jié)點。一旦有一個較長的鏈,那么惡意區(qū)塊攻擊就會完全失去它的威脅。除非攻擊者以每區(qū)塊12.5 BTC的代價繼續(xù)創(chuàng)建區(qū)塊,并將其傳播給 0.14.x版本軟件的節(jié)點,否則攻擊就是不可持續(xù)的。
換句話說,雖然這個漏洞的確存在著,但對 DoS攻擊的經濟刺激卻是相當低的。
超發(fā)漏洞
從0.15.0版本軟件開始,core軟件引入了一個新的特性,以便更快地查找和存儲UTXO,而這恰恰又引入了另一個漏洞。當一筆具有雙重支付單個交易的區(qū)塊納入區(qū)塊鏈時,軟件會將其視為有效,而不會出現(xiàn)崩潰的現(xiàn)象。
這就意味著一筆病理性交易(相同UTXO在同一交易中被使用多次,即案例2B),0.14版本的節(jié)點會因此而崩潰,而使用0.15版本軟件的節(jié)點卻會認為交易是有效的,這基本上是憑空在創(chuàng)建比特幣。
談談它是如何發(fā)生的。在0.15中出現(xiàn)的PR 10195 ,引入了很多內容,但它的主要要點在于改變了 UTXO的存儲方式,使得它們更有效地進行查找。因此,它出現(xiàn)了很多變化,包括對早期UpdateCoins函數的更改:
注意,assert(false) 周圍的代碼是如何被完全取出的。注意這一點,0.15.0中的PR 10537也更改了代碼。
assert失敗的條件現(xiàn)在取決于inputs.SpendCoin,它看起來是這樣子的:
本質上,SpendCoin返回“ false”值的唯一方法,就是讓幣不存在于UTXO集中。但正如你所看到的,這需要幣是FRESH的,而不是DIRTY的。這些不是常見的術語,但值得慶幸的是,core開發(fā)者Andrew Chow給出了解釋:
“現(xiàn)在的問題是,什么時候UTXO會被標記為FRESH?當它們被添加到UTXO數據庫時,它們就會被標記為FRESH。但是,UTXO數據庫仍然只存在于存儲當中的(作為緩存)。當它被保存到磁盤時,存儲中的條目將不再被標記為FRESH……”
標記為FRESH的幣,是進入交易存儲池(memory pool)中的幣。而攻擊者可以通過 UpdateCoins函數中的assert語句來破壞節(jié)點。更糟的是,如果幣是屬于DIRTY的(基本上從磁盤上讀取的),那么這就會導致比特幣的超發(fā)。
因此,攻擊者可以欺騙那些運行 0.15.0- 0.16.2版本軟件的礦工接受一個奇怪的、無效的區(qū)塊,從而導致比特幣的供應超發(fā)。
超發(fā)漏洞的嚴重性
這種攻擊的經濟誘因似乎明顯高于DoS攻擊,因為攻擊者可能會憑空制造出比特幣。但你仍然需要有挖礦設備來執(zhí)行攻擊,但考慮到潛在的經濟誘因,這可能是值得的,或者看起來是這樣的。
下面是使用這種漏洞的一種簡單攻擊方式:
1.創(chuàng)造一筆帶有雙重支付交易的區(qū)塊,其會向自己支付兩次,比方說 50 BTC →100 BTC;
2.將該區(qū)塊廣播給0.15/0.16版本客戶端的所有礦工;
下面是會發(fā)生的一些事:
1.0.14.x 版本節(jié)點會崩潰;
2.較舊版本的節(jié)點及其它替代客戶端會拒絕這個區(qū)塊;
3.很多區(qū)塊鏈瀏覽器是運行在自定義軟件上的,而不是基于core,因此,至少有一些瀏覽器會拒絕該區(qū)塊,并且不會顯示來自該區(qū)塊的任何交易。
4.取決于礦工們運行的軟件,我們可能會迎來鏈分裂;
有可能,所有的礦工都是運行的Bitcoin Core 0.15+版本軟件,在這種情況下,不受攻擊的客戶端可能會停滯不前。也有可能礦工會運行其它東西,在這種情況下,當他們發(fā)現(xiàn)一個區(qū)塊時,鏈就會發(fā)生分叉。
由于這些違規(guī)行為,網絡上的人們很快就會追蹤到這一點,可能已提醒一些開發(fā)人員,并且core開發(fā)者已經修復了它。如果存在分叉,那么在那個時候,關于哪條鏈是正確的共識鏈,將開始得到討論,而出現(xiàn)意外超發(fā)的鏈,可能會遭到拋棄。如果真的發(fā)生了,那么社區(qū)可能會自愿進行一次回滾,以懲罰攻擊者。
所以對于攻擊者來說,這不會帶來50 BTC的收入,更可能的是失去12.5 BTC。如果攻擊者加倍花費,比如說200 BTC,那么超發(fā)漏洞將持續(xù)存在的可能性會更小,因為攻擊會更明顯。
因此,從攻擊者的角度來看,這并不是一種好的獲利方式。
攻擊者可以獲利的另一種方式,就是事先做空比特幣,然后再執(zhí)行攻擊。這也是具有風險的,因為攻擊不能保證比特幣價格會下跌,特別是當危機得到迅速和果斷處理時。此外,考慮到大多數交易所提供的杠杠交易,都需要AML/KYC,這可能導致攻擊者很快暴露。
攻擊者不僅面臨著巨大的資金風險,而且還會有身體危險。從經濟角度來看,這并不是一個容易獲利的漏洞。
當然,有一些別有用心的人,可能會用這種漏洞來嚇唬那些比特幣持有者。投資回報率將變得更抽象,因此從理論上來講,這可能會達到這些別有用心者的目的。
結論
毫無疑問,這是一個相當嚴重的漏洞。盡管我和Awemany之間有著分歧,但我很感激他選擇公開地和我辯論。也就是說,考慮到經濟博弈理論,我不認為這個漏洞會像他所描述的那樣嚴重。
即使這個漏洞在被發(fā)現(xiàn)之前被壞人所利用,攻擊者可能也不會選擇利用它,因為從經濟學上來講,它是沒有意義的。可以肯定的是,這一技術漏洞應該被修復,并且開發(fā)者應該做得更好,但真正能夠利用這種漏洞的對象其實是非常少的,基本上,只有那些想要摧毀比特幣的組織才會這么干。
Bitcoin Core開發(fā)者的教訓有很多:
1、任何共識變化(即使是微小的變化,例如9049),也需要更多的人進行審查; 2、需要對病理交易進行更多的檢查; 3、代碼庫中哪些檢查是冗余的,哪些檢查是不冗余的,以及實際代碼將要做些什么,需要變得更加清晰; 4、過去存在漏洞,將來也會存在漏洞。現(xiàn)在重要的是,學習并反思這一教訓;
評論
查看更多