1. 程式人生 > >Qtum量子鏈漏洞賞金計劃正式開啟

Qtum量子鏈漏洞賞金計劃正式開啟

 本次Qtum量子鏈賞金計劃為了更好的藉助社群的力量參與到QTUM主網及周邊應用的開發建設中,讓QTUM持續地保持安全、高效的執行,同時能滿足更多使用者的需求。

Bug分級與獎勵體系

1、如果已經有類似的Issue或者Qtum團隊已經知道並在解決該問題的情況將不適用於該賞金計劃。

2、如果在解決前將問題公開,並造成危害的將不會獲得賞金。

3、修復時,請fork程式碼到自己的倉庫中進行修復,然後提交pull request在Qtum成員review之後正式合入主幹。

4、Qtum團隊成員是受僱於Qtum基金會,Qtum成員直接或間接的參與Bug修復的情況將不會獲得賞金。

5、賞金計劃以解決Qtum核心產品的技術,提升產品健壯性,Qtum網站、論壇、組織架構等不在賞金計劃之列。

6、賞金計劃的獎金與眾多因素有關、工作量、影響範圍、嚴重程度等,賞金計劃的具體賞金數額以QTUM安全團隊的結論為準且對於賞金計劃QTUM安全團隊有最終解釋權。

範圍

請在以下Github開源專案中查詢漏洞:https://github.com/qtumproject/qtum

這裡的範圍只是我們現在關注的重點產品,如果有未被列在上面,但是同樣是被驗證的軟體漏洞,我們也歡迎通過漏洞上報的方式進行上報和賞金申請,Qtum團隊將會對此作出評定並及時給予反饋。

這些漏洞可能會造成以下問題:

  • 損失、盜取使用者資產

  • 拒絕服務攻擊

  • 引起共識機制的失敗

  • 無法控制的通貨膨脹

  • 允許未經授權的訪問

漏洞等級分類

漏洞的等級與分類我們會參照OWASP 模型,我們將漏洞氛圍嚴重、高危、中危、低危、改進,具體定義方法請參考:http://www.owasp.org.cn/owasp-project/fengxian

需要注意的是:

1、 對於在比特幣、以太坊等網路上已上報的問題,賞金會相應的折算。

2、 以上獎勵數額為該級別漏洞的最高獎勵數額,具體的獎勵發放數額會由QTUM安全團隊決定。

對於獎勵的發放我們還會參照其中幾項來進行評審,如僅上報漏洞者,只需要關注上報材料一項。

上報材料(15%):完整填寫上報材料,具體請參考申報模板link,所有上報材料均為英文版本。

程式碼修復(40%):完成程式碼修復,並不引入新的問題,如果有新的問題被引入,需要在同一次提交中解決該問題。

自動化測試指令碼覆蓋或手動測試方法說明(15%):自動化測試指令碼對程式碼的持續整合、快速迭代下的質量控制有極其重要的作用,所以自動測試指令碼的完善會作為一項重要的考核指標:

提供自動化測試指令碼

100%

   提供手動測試說明

60%

修復時間與效率(20%):修復時間指Issue上報被確認後到修復程式碼被review過後合到程式碼庫間的時間,該時間會在Issue上報後QTUM安全團隊確認漏洞的反饋郵件中明確期望修復時間,該時間會與開發者協商。

該部分獎勵說明:

期望時間內完成

100%

超過期望時間50%內70%

70%

超過期望時間50%外

50%

 修復思路及方法介紹與文件完善(15%):對於修復完的漏洞,希望完成技術材料的整理與文件的提交,具體請參見:Bug修復後提交材料模板

漏洞的上報與修復流程

報告階段

報告者訪問「Bug上報」頁面(URL:https://qtum.org/zh/developer/long-term/bugs) 提交漏洞詳情(狀態:待稽核)

處理階段

1.一個工作日內,QTUM安全團隊會確認收到的漏洞報告並跟進開始評估問題, 同時將情報反饋給上報者(狀態:稽核中)

2. 三個工作日內,QTUM技術團隊處理問題、給出結論與期望完成時間(狀態:已確認/已忽略)。必要時會與報告者溝通確認,請報告者予以協助,評估完成後會將評估結果告知開發者。

修復階段

1.     提交者著手修復該安全漏洞(狀態:修復中)

2.     對於修復完成的問題,提交者可以將狀態改為(狀態:待複查)修復時間根據問題的嚴重程度及修復難度而定,一般來說,嚴重和高危問題 24 小時內,中危問題七個工作日內,低危問題十五個工作日內。客戶端安全問題受版本釋出限制,修復時間根據實際情況確定

3. QTUM安全團隊對問題進行復查,確認修復後會告知提交者結論和漏洞得分(狀態:已複查/複查異議)

材料整理階段

根據要求完成測試指令碼、手動測試說明、修復思路與文件完善等資訊

賞金髮放階段

QTUM安全團隊對提交人的材料完整性和修復完成度進行稽核併發布獎勵(狀態:已結束)

Bug上報模板

<!--- Remove sections that do not apply -->

This issue tracker is only for technical issues related to Qtum.

### Describe the issue

### Can you reliably reproduce the issue?

#### If so, please list the steps to reproduce below:

1.

2.

 ### Expected behavior

Tell us what should happen

### Actual behavior

Tell us what happens instead

### Screenshots.

If the issue is related to the GUI, screenshots can be added to this issue via drag & drop.

### What version of Qtum are you using?

List the version number/commit ID

 ### Machine specs:

- OS:

- CPU:

- RAM:

- Disk size:

### Any extra information that might be useful in the debugging process.

This is normally the contents of a `debug.log` or `config.log` file. Raw text or a link to a pastebin type site are preferred.

模板舉例

Title: DoS of stakers possible by sending a large transaction.

Description

An attacker can publish a very big transaction. This transaction will be accepted into the mempool, however, upon attempting to include that transaction in a block stakers will produce an invalid block that is not accepted by its peers.

Impact

It is possible for an attacker to cause a denial of service attack against all stakers on the network, effectively bringing block production to a halt.

Affected software

The core qtumd client.

Reproduction

  • Start qtumd      in regtest mode on a clean chain in staking mode: qtumd -regtest      -staking=1

  • Get some mature coins to enable      staking:  qtum-cli -regtest generate 600

  • Publish a really big transaction: qtum-cli -regtest sendtocontract ...

  • Wait for a minute while the staker      loop runs.

  • Inspect the      debug log

Expected result

The tx should have been rejected by AcceptToMemoryPoolWorker in step 3.

Actual result

  • The   transaction is accepted into the mempool.

  • The debug.log      has several entries of a block being rejected at each 16 second interval      due to it including a transaction that exceeds the maximum transaction      size.

Fix

Make sure that no transactions exceeding the maximum size are allowed into the mempool. This check should be implemented in AcceptToMemoryPoolWorker.

Files

Full debug.log

Bug修復後提交材料模板

###Fault cause

###Solution

###Resulting changes

###Resulting Document change

###Verify method

# Backwords compatible: (yes /no)

#Planned for version : (which version to deliver)

#New test case update/add/Manual testing:

References

  • https://docs.qtum.site

  • https://github.com/qtumproject