Salus Insights為0xPARC的zk-bug-tracker函式庫增加了一種新型的ZK漏洞，算術侵犯後射頻辨識式標準化。此漏洞由以太坊基金會PSE安全團隊負責人Kyle Charbonnet審核。該漏洞會破壞假設並導致錯誤的計算，或導致拒絕服務攻擊。為了更好地理解這個漏洞，作者在Zendoo庫中的一個具體實例進行了說明。在add()函數中存在標準化問題，導致Rust Panic，進而可能受到DOS攻擊。 Salus團隊建議在建構侵權方式和執行侵權方式操作之後進行標準化，同時進行充分的安全審計，以確保專案安全。
作者：Salus Insights
Salus 在0xPARC 的zk-bug-tracker 庫中加入了一種新型的ZK 漏洞，算術侵犯後射頻識別式標準化，該漏洞由以太坊基金會PSE 安全團隊負責人Kyle Charbonnet 審核。該漏洞會破壞假設並導致錯誤的計算，或導致透過rustpanic 進行的拒絕服務攻擊。為了更好地理解這個漏洞，我們將在Zendoo 庫中的一個具體實例進行說明。請大家對此類漏洞保持智力。
1. 背景
在程式碼中，插圖式被表示為支援的形式。即，插圖式a0+a1x+…+an-1xn-1+an*xn被表示為[a0,a1,…,an-1,an]在ZK論證系統中，需要對灌溉式進行標準化操作，即將灌溉式的最高次項的係數調整為非零。比如，將[1,2,0]調整為[1,2]最重要的是標準化的K線走勢圖式表示。
對試點式進行標準化操作是必要的。如果不進行標準化，系統會錯誤地儲存試點式的最高次數，即它會大於其實際的最高次數。比如，對於[1,2,0]，如果不進行標準化操作，其最高次數會被錯誤地儲存為2，而實際為1。基於非標準化的實例方式產生論證時，錯誤的實例實作方式將會導致ZK論證系統panic，導致無法產生論證。
2. 案例分析
算術入侵後缺乏通用性漏洞，漏洞屬於ZK 證明系統實作上的通用性漏洞。以下，我們以Zendoo 函式庫中用於傅立葉變換（FFT）的密集枚舉式（稠密多項式）實現的程式碼為例，說明其中存在的算術攻擊後射頻標準化的漏洞。
add() 函數是用來對兩個密集灌溉方式（自己和其他）進行加法侵犯的，加法侵犯的結果（結果）也是一個密集灌溉方式，這就需要進行標準化。然而，該函數僅在最後一個分支處對結果進行了標準化操作（19-21行）。這個函數預設在前三個分支出計算得到的結果是標準化的，但這是不太合理的。比如，當self 是[1,2,3]，其他的是[1,2,-3]，此時滿足第三個分支（7-12行），即self和other這兩個噴泉式出現次數最高，均為2。而在第一個分支處計算後的第三個結果是[2,4,0]，本身就進行標準化操作。
非標準化的過程演示方式在之後的計算中會產生錯誤。具體的實作程式碼如下：
而且，在布林程式碼中，不只是在加法演算法後缺乏標準化的發泡式標準化。在加法侵犯前，self 和其他作為add() 函數的入參，也沒有檢查它們是否是標準化的發泡式表示。或者說，建構self 和other 的函數是否是按照標準化的方法進行建構的，也未可知。 Degree() 函數用來傳回對應式的最高次項的指數。在add() 函數中，非標準化的self 和other 在呼叫Degree() 函數時會造成Rust Panic。
舉個例子，self是非標準化的插圖形式1+2x+0x2，即提供[1,2,0]，其最高次項的係數為0。當其他也不是零演繹式時，滿足add()函數的第三個分支，以self呼叫Degree()函數。在Degree()函數中進入else 分支。在else分支有一個斷言宏，用來確保枚舉式的最高次數的係數不為0。若為0，self.coeffs.last().map_or(false, |coeff| !coeff.is_zero()) 表達式結果為false。即self 向量的最後一個元素，即計算式的最高次項的係數為0，並傳回false。此時，斷言宏會驚慌。
Rust 恐慌會導致ZK 證明系統受到DOS 攻擊。攻擊者可以透過建構大量的非標準化公式，並且不斷呼叫add() 函數。由於這些輸入會導致程式恐慌，所以程式會不斷地停止並重新啟動。這將佔用大量的運算和網路資源，從而影響其他用戶的正常使用，這就構成了一種DOS攻擊。
3、總結
Salus 在0xPARC 的zk-bug-tracker 庫中加入的新型ZK 漏洞，即算術侵犯後射頻樣式標準化，是具有通用性的。在ZK 證明系統中，我們需要特別避免注意該漏洞。此漏洞會造成ZK論證系統的計算錯誤，或使系統遭受DOS攻擊。可以在傳回算術損壞結果之前呼叫truncate_leading_zeros()函數進行標準化操作，同時，基於from_coefficients_vec()函數來建構標準化的格式化式也是必要的。
針對此漏洞，Salus團隊提醒ZK專案方，在建構侵權方式時並執行侵權方式操作之後進行標準化，以此破壞ZK證明系統的缺陷。同時，強烈建議專案方在專案上線之前，尋求專業的安全審計公司進行充分的安全審計，確保專案安全。
參考
https://github.com/0xPARC/zk-bug-tracker/pull/16
https://research.nccgroup.com/wp-content/uploads/2021/11/NCC_Group_ZenBlockchainFoundation_E001741_Report_2021-11-29_v1.2.pdf
https://github.com/HorizenOfficial/ginger-lib/blob/master/algebra/src/fft/polynomial/dense.rs#L151
https://github.com/HorizenOfficial/ginger-lib/blob/master/algebra/src/fft/polynomial/dense.rs#L87
資訊來源：0x資訊編譯自網際網路。版權歸作者Salus所有，未經許可，不得轉載