StandardBounties V2 Vulnerability Report

On September 4th, we were notified that the team from Mixbytes had discovered a new vulnerability in our contract code, which allowed for users to potentially refund their contributions a second time if they’d already been refunded by the issuer of a given bounty.

An example of the attack vector:

A contributor C1 makes a contribution of 10 Ether with contribution id = 0.

A contributor C2 makes a contribution of 10 Ether with contribution id = 1.

An issuer I1 that does not relate in any way to C1 or C2 issues a refundContributions call with the _contributionIds parameter being equal [1].

As a result of this call, C2 receives 10 Ether back. After the call, the balance of the bounty is 10 Ether.
C2 issues a refundContribution call with the _contributionId parameter being equal to 1. As a result of this call, C2 receives the remaining 10 Ether.

Ultimately, C2 received a double refund, and the contribution of C1 was in fact transferred to C2. The balance of the bounty is 0, despite the fact that the issuer intended to refund only C2.

The nature of this bug was such that it first required bounty issuers to refund a set of contributions en masse, but leave a subset of the funds in the bounty remaining (for a contributor to then re-refund themselves). This mass-refund function wasn’t one which we’d implemented on our front-end, and could only be accessible through customized interfaces, or by interacting directly with the smart contract in a manual fashion. We therefore decided the likelihood of funds being at risk was fairly low, and delayed announcing this issue until the fix was ready.

As soon as we discovered this issue, we notified the original team which had performed our smart contract audit (ConsenSys Diligence), and immediately began work on a new version of the contract which fixed this issue.

The new version of our contracts (V2.1) has now been deployed, and the new code is now live for use by the public. We’re glad to say no users were able to exploit this esoteric bug in the time it took us to update our codebase and test it to ensure no new bugs would arise from the patch.

We remain incredibly thankful for the Mixbytes team who performed the audit, and the Autark team that triggered a new audit of the code (and has been a delight to work with as they develop an integration between Bounties Network and Aragon).

While we remain diligent about following best practises around deploying smart contract code — complete with both programmatic and manual testing, code reviews, 3rd party code auditing, and finally a public bug bounty (none of which were able to surface this issue) — this occurrence serves as an important reminder that any code written by humans is susceptible to human errors and bugs.

We look forward to continuing to support an open protocol for Bounties on Ethereum, and working with as many teams as we can to ensure maximal interoperability and standardization to the benefit of our users and the broader Ethereum community.