這篇文章要討論的是一個關於 Git 簽名機制與 GitHub 驗證邏輯之間的深層漏洞。對於許多工程師來說，我們習慣認為一個經過簽名且顯示為 Verified 的 Commit Hash（提交哈希值）就是該版本代碼的唯一且不可更改的指紋。但最新的研究發現，這個假設在實務上是不成立的。
首先，我們需要理解 Git 的 Commit Hash 是如何產生的。一個 Commit 的哈希值是由其內容（包含檔案快照、作者、日期以及簽名數據本身）經過雜湊函數計算而來的。這意味著只要提交物件中的任何一個位元組發生改變，產生的哈希值就會完全不同。
而這次發現的漏洞核心在於簽名可延展性（Signature Malleability）。簡單來說，在密碼學中，某些簽名方案允許在不改變簽名有效性的情況下，將簽名數據改寫成另一種形式。因為簽名數據本身就包含在 Commit 物件中，如果攻擊者將簽名改寫，雖然簽名依然有效（驗證會通過），但整個 Commit 物件的內容變了，導致產生的 Commit Hash 也隨之改變。
具體來說，這種攻擊在不同簽名方案中有不同的實現方式。在 ECDSA（橢圓曲線數位簽名演算法）中，可以利用數學對稱性將簽名值 s 轉換為 n-s，兩者在驗證時都被視為有效。而在 RSA 或 EdDSA 中，攻擊者可以在簽名的非雜湊區域加入被忽略的額外欄位。至於 S/MIME 則可以透過改寫長度欄位為非標準格式來達成。
這對開發者與安全維運人員有什麼實際影響？
最直接的風險在於那些依賴 Commit Hash 作為黑名單或唯一識別碼的系統。假設安全團隊發現了一個惡意的提交並將其哈希值加入封鎖名單，攻擊者可以使用此漏洞，將完全相同的代碼與簽名重新編碼，產生一個全新的、同樣帶有 Verified 標章的哈希值。由於這個新哈希不在封鎖名單中，惡意代碼就能再次繞過檢查被推送上去。
此外，這會影響到供應鏈的追溯與重複構建（Reproducible Builds）。如果鏡像站點被篡改，攻擊者可以提供一個內容完全一樣但哈希值不同的簽名提交，導致追蹤紀錄與原始倉庫不一致，而審核者在 GitHub 上看到的依然是令人安心的 Verified 標章。
這裡需要澄清一個重點：這並不是雜湊碰撞（Hash Collision），也沒有破解 SHA-1 或 SHA-256。攻擊者無法透過這個方法在不持有私鑰的情況下修改代碼內容。如果你在設定中鎖定了特定的 Commit Hash（Pinning），你依然會拿到正確的代碼，因為哈希值改變了，鎖定就會失效或指向不同的物件。
為什麼這個問題會存在？
問題出在 GitHub 在驗證簽名之前，沒有對簽名數據進行標準化（Canonicalization）。它接受了多種等價但格式不同的簽名表達方式，並為每種形式的哈希值都標記為 Verified。這就像是同一把鑰匙有兩種不同的外觀，雖然都能開鎖，但系統卻把它們記錄成兩把不同的鑰鑰匙。
這類問題在區塊鏈領域早已有之。例如比特幣早期就遇到過 ECDSA 簽名可延展性導致交易 ID 改變的問題，最終透過強制要求使用低 S 值（low-S）以及引入 SegWit 將簽名移出交易 ID 的計算範圍來解決。
對於目前的開發者而言，最安全的做法依然是將 GitHub Actions 或第三方模組鎖定在完整的 Commit Hash 上，而非使用可變動的 Tag。雖然這次漏洞顯示哈希值可以被偽造出多個版本，但只要你鎖定的是某個特定的哈希，你獲取的內容就一定是該哈希對應的內容。
真正的修復責任在於 GitHub 等平台方。平台應該在計算哈希或驗證之前，先將簽名數據標準化為唯一格式，確保同一份簽名內容只會對應到一個唯一的 Commit Hash。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。