作者：Optech
來源：https://bitcoinops.org/zh/newsletters/2024/07/05/
本文來自 Bitcoin Optech Newsletter #310 的新聞部分。譯本由 “Optech 中文翻譯小組（BitcoinOptechCN）” 提供。
原文總結了最近披露的影響 0.21.0 以前版本的 Bitcoin Core 軟件的安全漏洞。為方便讀者判定自己正在使用的軟件版本的安全性，按照修復的時間倒序重新排列了漏洞的敘述。使用越新版本的用戶需要嚴肅閱讀的部分越少越靠前。
我們深知，軟分叉哲學是比特幣開發哲學的核心部分，它賦予了用戶選擇自己喜愛的共識規則的自由，因此，舊版本軟件的安全性是所有人都應該捍衛的東西，如果沒有它，軟分叉哲學及其相應的自由就是一種空談。但是，軟件也像別的產品一樣，有設計的使用週期，指望一款軟件產品可以得到永續的安全維護是不現實的。因此，最終來說，全節點的運營者必須承擔起判斷的責任：在使用一款軟件之前，評估其安全性，並隨著信息的披露，更新自己的評估。
影響 0.21.0 以前版本 Bitcoin Core 的漏洞披露：Antoine Poinsot 在 Bitcoin-Dev 郵件組中貼出了一個鏈接，公佈了 10 個影響已經退役接近兩年的 Bitcoin Core 軟件版本的漏洞。我們將披露總結如下：
源自過量時間調整的網絡分裂：舊版本的 Bitcoin Core 允許自身的時鐘被它連接到的前 200 個對等節點所報告的時間扭曲。這些代碼本意是允許不超過 70 分鐘的扭曲。所有版本的 Bitcoin Core 軟件都會暫時無視帶有超過本地時間 2 個小時以上的時間戳的區塊。兩個 bug 的組合，讓攻擊者可以讓受害者的時鐘倒撥兩個小時以上，使之忽略掉帶有準確時間戳的區塊。該漏洞由開發者 practicalswift 盡責披露，並在 Bitcoin Core 0.21.0 中得到了修復。
審查未確認的交易：對等節點一般會通過交易的 txid 或 wtxid 來宣佈新交易。在節點第一次看到一個 txid 或者 wtxid 時，它會從第一個宣佈這筆交易的對等節點處請求完整的交易。在等待這個對等節點回復的時間裡，節點也會跟蹤其它宣佈了相同 txid 或 wtxid 的對等節點。如果第一個對等節點不回覆、直至超時，節點會從第二個節點處請求完整交易（如果再次超時，則轉向第三個節點，以此類推）。
在 Bitcoin Core 0.21.0 之前，節點最多隻會跟蹤 50000 個請求。所以，第一個對等節點在宣佈一個 txid 之後，可以推遲迴復節點對完整交易的請求，等待該節點的其它對等節點都宣佈該筆交易，然後發送 50000 條關於其它 txid 的宣佈（可以都是假的 txid）。如此一來，當節點對第一個對等節點的完整交易請求超時後，它將不會再向其它任何對等節點請求完整交易。攻擊者（第一個對等節點）可以無限重複這種攻擊，從而永久阻止節點受到這比交易。請注意，這種對未確認交易的審查可以阻止交易迅速得到確認，這可能導致合約式協議（比如閃電通道）中的資金損失。John Newbery 引用了來自 Amiti Uttarwar 的共同發現，負責地披露了這個漏洞。修復措施在 Bitcoin Core 0.21.0 中放出。
無限大小的禁止連接列表所帶來的 CPU/內存 DoS：Bitcoin Core PR #15617（首次包含在 0.19.0 中）添加了代碼，使得在收到一條 P2P
getaddr消息時，檢查被本地禁止連接的 IP 地址，最高可達 2500 次。節點的禁止連接列表的長度時不受限制的，如果一個攻擊者控制了大量的 IP 地址（例如，易於獲得的 IPv6 地址），這份列表會膨脹成巨大的規模。當這個列表變得很長的時候，每一次getaddr請求都可能消耗超量的 CPU 和內存，可能讓節點不可用甚至崩潰。這個漏洞被編號為 CVE-2020-14198，在 Bitcoin Core 0.20.1 中得到了修復。嘗試解析 BIP72 URI 而導致的內存崩潰：0.20.0 以前的 Bitcoin Core 支持延伸了 BIP21
bitcoin:URI 的 BIP70 支付協議、使用由 BIP72 定義的參與r來引用一個 HTTP(S) URL。Bitcoin Core 會嘗試從這個 URL 上下載文件，並存儲在內存中等待解析，但是，如果這個文件大於可用的內存，Bitcoin Core 最終就會終止。當嘗試下載在後臺發生時，用戶可能會走開，因此沒有注意到節點的崩潰、也沒有重啟關鍵的服務。這個漏洞由 Michael Ford 盡責披露，並由 Bitcoin Core 0.20.0 通過移除 BIP70 支持的方式修復（見週報 週報 #70）。來自大體積
inv消息的內存 DoS ：一條 P2Pinv消息可以包含一個高達 50000 個區塊頭哈希值的列表。在 0.20.0 版本以前，新式 Bitcoin Core 節點會為自己不理解的每一個哈希值回覆一條單獨的 P2Pgetheaders消息，而這樣的消息的體積將是約 1 kB。這導致節點會在內存中存儲大約 50 MB 的消息，等待對等節點接收它們。每一個對等節點都可以這樣做（而對等節點的數量默認可達大約 130 個），這就會在節點的常規內存要求之上額外使用超過 6.5 GB 的內存 —— 足以讓許多節點崩潰。崩潰的節點可能無法處理為合約式協議的用戶處理時間敏感的交易，可能導致用戶損失資金。John Newbery 負責地披露了這個漏洞，並提供了一種修復措施：僅用一條getheaders消息來回復一條inv消息，無論後者包含了多少哈希值；此修復進入了 Bitcoin Core 0.20.0。通過格式錯亂的請求浪費 CPU 的 DoS：在 Bitcoin Core 0.20.0 以前，攻擊者或出故障的對等節點可以發送一種格式錯亂的 P2P
getdata消息，導致處理消息的線程消耗 100% 的 CPU。（攻擊發生後）在連接持續時間內，節點將不再能從攻擊者處接收消息，雖然還能從誠實對等節點處收取消息。對於擁有少數 CPU 核心的節點來說，這可能只會造成一些小問題；在別處就會變成一種麻煩。John Newbery 負責地披露了這個漏洞並提供了一種修復措施；該措施進入了 Bitcoin Core 0.20.0。因處理孤兒交易而產生的 CPU DoS 以及節點卡頓：Bitcoin Core 節點會跟蹤 “孤兒交易” 的一個不超過 100 筆交易的緩存，對於這些交易，節點在交易池和 UTXO 集中還沒有必要的父交易信息。在驗證完一筆新交易之後，節點會檢查孤兒交易中是否有某一個變得可以處理。在 Bitcoin Core 0.18.0 之前，每次檢查孤兒交易緩存的時候，節點都會嘗試使用最新的交易池和 UTXO 狀態、驗證每一筆孤兒交易。如果這 100 筆緩存的孤兒交易都被構造成需要大量的 CPU 來驗證，節點可能會浪費超量的 CPU，可能因此無法處理新區塊和新交易長達數小時。這種攻擊基本上時免費的：孤兒交易時可以免費創建的，因為它們可以引用根本不存在的父交易。一個停滯的節點將無法生成區塊模板，因此這種攻擊可能會被用來阻止一個礦工獲得收益，而且可以用來阻止交易得到確認、可能會導致合約式協議（例如閃電通道）的用戶失去資金。開發者 sec.eine 盡責披露了這個漏洞；該漏洞在 Bitcoin Core 0.18.0 中修復了。
使用低難度區塊頭的內存 DoS：自 Bitcoin Core 0.10 以來，節點會請求其每一個對等節點來發它們所知的 最佳區塊鏈（累積最多工作量證明的有效區塊鏈）的區塊頭。這種方法的一個已知問題是，一個惡意的對等節點可以用大量低難度（例如，難度 1）的假冒區塊頭來轟炸節點，這樣的區塊頭用先進的 ASIC 挖礦設備是很容易創建的。Bitcoin Core 最初的解決方法是僅接受與代碼內硬編碼的 檢查點 相匹配的區塊鏈上的區塊頭。最後一個檢查點，雖然來自 2014 年，但以現在的標準來說也具有一個相對高的難度，所以它會要求大量地做功來創建假冒的區塊頭。但是，Bitcoin Core 0.12 加入的一項代碼變更開始允許節點接受低難度的區塊頭進入內存，潛在地讓攻擊者可以用假冒區塊頭填滿內存。這可以會導致節點宕機，並進一步導致合約式協議（比如閃電通道）的用戶損失資金。Cory Fields 負責地披露了這個漏洞；該漏洞在 0.15.0 中修復。
因 miniupnpc 而出現的遠程代碼執行漏洞：在 Bitcoin Core 0.11.1（發佈於 2015 年 10 月）以前的版本中，節點會默認啟用 UPnP 以允許通過 NAT 的入站連接。這是使用 miniupnpc 庫 來實現的，而後者已被 Aleksandar Nikolic 發現具有多個可被遠程攻擊的漏洞（CVE-2015-6031）。這些流動在上游庫中修復了，修復也進入了 Bitcoin Core，並且開發者們採取了一項更新：默認禁用 UPnP。在研究這個 bug 的過程中，Bitcoin 開發者 Wladimir J. Van Der Laan 發現了同一庫中的另一個遠程代碼執行漏洞。該漏洞已得到盡責披露，並已在上游庫中修復，也進入到了 Bitcoin Core 0.12 中（發行於 2016 年 2 月）。
來自多個對等節點的大體積消息可造成節點崩潰：在 Bitcoin Core 0.10.1 之前，節點對 P2P 消息的體積要求是不能超過（約）32 MB。並且，一直以來（直到現在），節點默認允許高達 130 個連接。如果每個對等節點都在幾乎同一時間發送最大體積的消息，這會讓節點需要在其它內存要求之上額外劃出 4 GB 的內存空間，已經超過了許多節點能夠提供的大小。這個漏洞是由 BitcoinTalk.org 論壇的用戶 Evil-Knievel 盡責披露的，獲得了編號 CVE-2015-3641，並且在 Bitcoin Core 0.10.1 中修復了，修復方法是將消息的體積限制在 2 MB 之下（後續又為了隔離見證升級而提高到約 4 MB）。
