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修复后提交材料模板

 

漏洞的上 与修复流程

 

告阶段

 

处理阶段

 

2. 三个工作日内，QTUM技术团队处理问题、给出结论与期望完成时间(状态：已确认/已忽略)。必要时会与 告者沟通确认，请 告者予以协助，评估完成后会将评估结果告知开发者。

 

修复阶段

1.     提交者着手修复该安全漏洞(状态：修复中)

2.     对于修复完成的问题，提交者可以将状态改为（状态：待复查）修复时间根据问题的严重程度及修复难度而定，一般来说，严重和高危问题 24 小时内，中危问题七个工作日内，低危问题十五个工作日内。客户端安全问题受版本发布限制，修复时间根据实际情况确定

3. QTUM安全团队对问题进行复查，确认修复后会告知提交者结论和漏洞得分(状态：已复查/复查异议)

 

材料整理阶段

根据要求完成测试脚本、手动测试说明、修复思路与文档完善等信息

 

赏金发放阶段

 

Bug上 模板

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

### Describe the issue

 

### Can you reliably reproduce the issuep>

 

#### 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 usingp>

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