在以太坊上安裝 「炸彈」

本文是講解我在 go-ethereum（Geth）客戶端中發現的 Bug 系列的第二篇。

這篇文章要講的 bug 位於 Geth 客戶端的狀態下載器內，它可以用來欺騙下載器，使之不能與主網正確同步。攻擊者可以利用這個 bug 給以太坊區塊鏈設置陷阱、任意觸發硬分叉。

同步

當你想運行一個以太坊節點的時候，首先必須同步上整個網路，即，下載和計算構建最新區塊時刻的區塊鏈狀態所需的所有數據。根據用戶自身的需要，同步方式可以在安全性和速度之間有所取捨，所以（在撰文之時） Geth 支持兩種同步模式：完全同步和快速同步。

顧名思義，完全同步就是獨立地執行完對以太坊區塊鏈的整個同步過程。這就意味著，你的 Geth 節點會下載和驗證每個區塊的工作量證明（PoW），此外，它還會計算區塊內的每一條事務；由此，節點可以在本地生成區塊鏈的最新狀態，而無需信任其它節點。這種模式更安全，但速度上有很大犧牲。Geth 的完全同步可能要花幾天乃至幾周不等的時間。

但是，有些用戶可能不想等上幾周。也許他們的時間很緊，又或者，他們並不覺得這種犧牲是值得的。因此，Geth 提供了一個模式：在近期的某個區塊（稱為 「pivot 區塊」）之前的所有鏈數據，都用更快的方法來同步，只有 pivot 區塊之後的區塊鏈，才使用更慢的完全同步演算法。在快速同步模式中，Geth 會下載區塊，但僅隨機選取一些區塊來驗證工作量證明，而不是每個區塊都驗證；而且，它也將不再自己執行事務，而是從網路中的其它節點處直接下載狀態樹，以此獲得最終的區塊鏈狀態。

當然，Geth 也不會盲目相信其他節點發回的狀態樹數據，因為一個惡意的節點也可以聲稱某個賬戶只有一點點錢（但實際有很多）。要理解 Geth 如何能辨別收到的數據正確與否，我們先要理解默克爾帕特里夏樹（Merkle-Patricia trie）。

默克爾帕特里夏樹

默克爾帕特里夏樹（MPT）是 Geth 客戶端中的一種關鍵數據結構，它是默克爾樹和帕特里夏樹兩者的結合。

簡而言之，帕特里夏樹會基於數據的前綴將數據存到一個樹狀結構中。相較於其它技術（如哈希表，hashmap）來說，帕特里夏樹本身非常適合存儲相似的數據，儘管在速度上可能有所犧牲。下面來看看，多個以 r 開頭的單詞是如何存到一棵帕特里夏樹里的。

接著來說說默克爾樹。在一棵默克爾樹上，每個葉節點是數據的哈希值，每個非葉節點是它的兩個子節點的哈希值。如果用戶知道了默克爾樹的默克爾根（即，頂端哈希值），並且想要確認某個數據是否存儲在這棵樹里，他只需要用到這棵樹上的一條路徑，這條路徑所涉及的節點數量只跟葉節點數量的對數（注意不是葉節點數量）成正比。如下圖所示，假設用戶要證明 L2 存儲在這棵樹里，他只需提供 Hash 0-0 和 Hash 1。接著，驗證者生成 Hash 0-1、Hash 0 和 Top Hash，再將 Top Hash 與其所預期的默克爾根進行比較。

默克爾帕特里夏樹將帕特里夏樹基於前綴的存儲結構與默克爾樹相結合，創造出了一種新的數據結構，不僅支持密碼學驗證方式，而且還能保持良好的運行時性能。

在默克爾帕特里夏樹中，鍵和值都是任意的位元組串。要想獲得一個鍵的值，我們首先要將這個鍵轉換成一個十六進位字元序列，即，將每個位元組變成兩個十六進位字元。然後，我們要先根據序列中的第一個字元，向根節點查詢下一個節點是什麼；得到此子節點後，再根據第二個字元向下查詢節點，依次類推，直至找到最後一個節點，獲得最後一個字元。

在下面這個例子中，我們可以看到默克爾帕特里夏樹實際上包含三種不同的節點。擴展節點（在 Geth 代碼庫中又被稱為短節點）是經過優化的，負責存儲一連串字元。在下圖所示案例中，根節點存儲了所有以 a7 開頭的鍵，無需使用兩個不同的節點來代表 a 和 7。分支節點（或稱 「完整節點」）包含每個可能字元的指針以及一個額外的空檔來存儲當前節點的值。最後，葉節點（又稱值節點）的 key-end 欄位必然與其所存儲的 key 的後綴相匹配 1 。

狀態樹

既然我們已經知道默克爾帕特里夏樹是如何運作的了，我們可以開始探究什麼是全局狀態樹。

區塊鏈的絕大部分數據都存儲在全局狀態樹中。雖然將狀態樹作為獨一無二的實體包含在每個區塊內這個設想看似便利，但實際上每個區塊都要複製完整的狀態樹是極其低效的，因為每個區塊之間的狀態樹只有細微差別。Geth 採用了不同的方案。你可以想像一下，Geth 維護了一個 MPT 節點池。每個區塊的狀態樹只是整個池的子集。每當有新的區塊被挖出或導入，就會有新的 MPT 節點被添加到池中。

要想識別節點池中的根節點，我們必須查詢區塊頭。每個區塊都包含一個指向 stateRoot 的欄位，該欄位指向 MPT 的根節點（而該 MPT存儲以賬戶地址 2 作為鍵的賬戶數據）。這樣一來，Geth 就可以使用我們上文描述的演算法查詢賬戶信息，如任意地址的 nonce 或餘額。

請注意，如果是合約的話，賬戶狀態將包含一個非空的 storageRoot 欄位和 codeHash 欄位。storageRoot 欄位指向另一個根節點。但是，此時所涉及的 MPT 的用途是存儲該合約的存儲項數據；該 MPT 會將存儲空檔（storage slot）作為鍵，將原始數據作為值。

為了將 MPT 存儲在磁碟上，Geth 選擇使用 LevelDB 作為資料庫。然而，LevelDB 是只支持字元串到字元串映射的鍵值資料庫，MPT 不是字元串到字元串映射。為了解決這個問題，Geth 將每個節點編寫成鍵值對，從而實現全局狀態樹的扁平化：將節點的哈希值作為鍵，將序列化的節點作為值。這樣一來，Geth 就能查詢任意區塊的狀態樹，因為區塊頭中的 stateRoot 欄位就是鍵，可以用來查找 LevelDB 中的序列化 MPT 節點（譯者註：即一棵 MPT 的根節點）。

樹混亂

因此，假設你啟動了一個 Geth 節點，並使用快速同步模式連接到網路。Geth 將快速下載所有區塊數據，但是不執行任何事務。不久之後，你將得到一個沒有狀態信息的區塊鏈。此時，Geth 通過狀態下載器從 pivot 區塊的 stateRoot 開始進行同步。

// NewSync creates a new trie data download scheduler.func NewSync(root common.Hash, database ethdb.KeyValueReader, callback LeafCallback, bloom *SyncBloom) *Sync { ts := &Sync{ database: database, membatch: newSyncMemBatch(), requests: make(map[common.Hash]*request), queue: prque.New(nil), bloom: bloom, } ts.AddSubTrie(root, 0, common.Hash{}, callback) return ts}

狀態下載器會向對等節點請求與 MPT 節點鍵對應的 MPT 節點數據。收到結果後，狀態下載器會對節點數據進行哈希計算，驗證得到的哈希值是否與節點鍵相同。如果相同，狀態下載器就知道這個 MPT 節點是正確的，然後就會發送更多請求，請求該 MPT 節點的每個子節點。

 // Create and schedule a request for all the children nodes requests, err := s.children(request, node) if err != nil { return committed, i, err } if len(requests) == 0 && request.deps == 0 { s.commit(request) committed = true continue } request.deps += len(requests) for _, child := range requests { s.schedule(child) }

如果遇到葉節點（包含序列化的賬戶狀態），賬戶的代碼和狀態樹將排隊等待被獲取。

callback:=func(leaf[]byte, parentcommon.Hash) error{varobjAccountiferr:=rlp.Decode(bytes.NewReader(leaf), &obj); err!=nil{returnerr}syncer.AddSubTrie(obj.Root, 64, parent, nil)syncer.AddRawEntry(common.BytesToHash(obj.CodeHash), 64, parent)returnnil}

請注意同步子樹和原始條目之間的區別。雖然二者都下載任意的數據塊，但是如果同步器預期要同步的是原始樹，它會將該數據解析為樹節點，並開始同步其子節點。另一方面，如果同步器預期要同步的是原始條目，它會將數據塊寫入資料庫並終止。

// If the item was not requested, bail outrequest:=s.requests[item.Hash]ifrequest==nil{returncommitted, i, ErrNotRequested}ifrequest.data!=nil{returncommitted, i, ErrAlreadyProcessed}// If the item is a raw entry request, commit directlyifrequest.raw{request.data=item.Datas.commit(request)committed=truecontinue}

另外還要注意的是，Geth 想要多次向同一個節點發送請求的情況並不少見。例如，如果兩個合約存儲相同的數據，那它們的 stateRoot 可能相同，也有可能出現兩個賬戶擁有同樣的賬戶狀態。在這些情況下，Geth 不想讓網路充斥這些請求，因此會將它們合併。

func(s*Sync) schedule(req*request) {// If we're already requesting this node, add a new reference and stopifold, ok:=s.requests[req.hash]; ok{old.parents=append(old.parents, req.parents...)return}// Schedule the request for future retrievals.queue.Push(req.hash, int64(req.depth))s.requests[req.hash] =req}

然而，同步器不會合併請求的 raw 屬性。這意味著，如果已經有了一個未決的原始條目請求，但是同步器又安排了一個具有相同哈希值的子樹請求，後者將被合併，最終結果還是只有一個原始條目請求。

請記住，原始條目請求不會為了同步子節點而處理節點（不像子樹請求）。這意味著，如果我們能以某種方式在原始條目和子樹節點之間引發衝突，我們就能讓 Geth 同步一個不完整的狀態樹。另外，遇到一個本地不存在的樹節點時，Geth 不會退出（報錯），這等於是假設，如果下載器報告同步成功，這種（本地缺失狀態數據的）情況就不會發生。這就意味著，缺少一個樹節點的 Geth 節點在行為上與其它完全同步樹的節點截然不同。

那麼，如何引發衝突呢？事實證明非常簡單：我們只需用我們控制的某個合約的序列化狀態根部署另一個合約，因此該合約代碼的哈希值必定與（我們所控制的合約的）狀態根哈希值相同，這就意味著如果合約代碼先同步，另一個合約的狀態樹不會被全部下載下來。

綜上

如果有人利用這個漏洞作惡，需完成要多個步驟並等待很長時間。

首先，我們部署一個合約（我們會利用漏洞將這個合約的狀態樹覆蓋掉）。這個合約應該有一個獨一無二的 stateRoot，從而避免與這個 stateRoot 相關的 MPT 節點提前同步。

contract Discrepancy { uint public magic = 1; // make sure we have a unique stateRoot uint[] private filler = [1,2,3,4,5,6,7,8,9,0];}

接著，我們部署第二個合約，以便利用矛盾觸發硬分叉。

contract Hardfork { function hardfork(Discrepancy target) public { require(target.magic() == 0, "no discrepancy found"); selfdestruct(msg.sender); }}

最後，我們用 Discrepancy 合約的狀態根作為代碼部署第三個合約。這裡我們必須注意一點，第三個合約的地址要比 Discrepancy 合約的地址 「小」，從而確保它始終先於 Discrepancy 合約同步。

contract Exploit { constructor(bytes memory stateRoot) public { assembly { return(add(stateRoot, 0x20), mload(stateRoot)) } }}

現在我們就大功告成了。當新的 Geth 節點使用快速同步加入網路時，它們會先請求 Exploit 合約，同步其狀態子樹及代碼。當 Exploit 合約的代碼被同步時，它會創建一個看起來與 Discrepancy 的狀態根請求完全相同的原始條目請求，但它不會被當作子樹請求處理。這意味著，該節點永遠不會下載 Discrepancy 的狀態 trie，因此未來讀取 magic 的請求將返回 0 而非 1。

經過足夠長的時間後，我們要做的就是調用 Hardfork.hardfork(discrepancy)。每個正確同步整個網路的節點都會看到一個回滾交易，而每個使用快速同步加入網路的 Geth 節點都會看到一個成功的交易。這將導致一個區塊產生兩個不同的狀態根，也就是說我們可以隨心所欲地觸發鏈分裂。

Geth 團隊通過處理 PR #21039 中的樹讀取錯誤快速解決了該攻擊，然後通過區分 PR #21080 中的代碼部分和樹部分完全修復了這個漏洞。

結論

這是一個非常有趣的漏洞，它可以讓攻擊者在以太坊網路上設置一個 「炸彈」，並隨時引爆，從而導致所有使用快速同步的 Geth 節點從主網中分叉。這個陷阱利用的是 Geth 的同步和數據存儲代碼中極其複雜的邏輯，這或許是它很長時間來都沒有引起人們注意的原因。

敬請期待本系列的第三篇也是最後一篇文章。在這篇文章中，我們將探索 Geth 客戶端的最新 bug，具體細節不便透露。

腳註

1. 從技術層面來說，Geth 中的值節點不包含後綴。你可以將其理解成一個後面跟著值節點（只包含原始數據）的擴展節點。

2. 實際上，Geth 使用的是 「安全的 trie」，即，通過 SHA-3 演算法對所有鍵進行哈希計算，從而確保所有鍵都是固定長度。

（完）

冷萃財經原創，作者：Awing，轉載請註明出處：https://www.lccjd.top/2021/06/10/%e5%9c%a8%e4%bb%a5%e5%a4%aa%e5%9d%8a%e4%b8%8a%e5%ae%89%e8%a3%85-%e7%82%b8%e5%bc%b9/?variant=zh-tw