StandardBounties Bug Discovered

While no funds are at risk, we continue to monitor the bug as we migrate our contract to a new version with stronger security guarantees.

When we first began working on StandardBounties, it was because we saw people posting bounties with ETH and ERC20 tokens by writing brand new contracts from scratch for one-off use. We knew there needed to be an easier way for people to publicly collateralize their requests for work, without having to worry about writing code, or making sure it was secure themselves.

Immediately after deploying StandardBounties into production on MainNet, we launched a bug bounty program awarding between 1 and 10 ETH, depending on the severity of submitted bugs. We have consistently believed that smart contract security should be taken seriously, which means relying on both private auditing alongside public bug bounties that positively incentivize hackers to disclose bugs responsibly.

What Happened

On November 6th, the Bounties Network team was notified by Oleksii Matiiasevych from Ambisafe, that there was a re-entrancy bug written in the original StandardBounties contract that we deployed last December, which didn’t affect any funds in the contract.

The essence of the bug is:

On line 218 of StandardBounties, a user issuing a new bounty performs a token transfer before completing all necessary state changes, meaning the token contract can potentially re-enter, to take advantage of the non-atomic state transitions currently underway.

A malicious actor could call the issueAndActivate function, issuing a bounty which intends to pay out in the malicious token contract. When the transferFrom call is performed on line 218, the malicious contract can once again call issueAndActivate, creating a new bounty and overriding the token contract address which is stored at tokenContract[bounties.length] .

As a result of this bug, a malicious actor would be able to issue bounties which are corrupted, i.e. they would have a tokenContract address which is 0x0, but the paysToken field of the struct would be set to true, meaning that any attempted payouts would eventually fail (as no legitimate token contract resides at the 0 address).

After spending a significant amount of time researching this bug, we don’t believe there’s any way it can allow byzantine bounty issuers to administer funds which they haven’t deposited. Now that we’ve taken the time to understand the implications of this bug, we wanted to immediately disclose it to the community, because we care deeply about the integrity of our contracts, and we understand how important it is to be communicative about their status in an open and honest manner.

As of the time of writing, the only implication we have discovered is the one outlined above: that corrupted bounties can be created. No one else’s bounties can be altered, nor can their funds be touched.

Since a different re-entrancy bug was discovered last year and we were forced to re-deploy without buggy functionality, we’ve been itching to upgrade our contracts to have stronger security guarantees. However, throughout this upgrade process, we’ve chosen to extend our timeline in order to integrate as many features as possible based on feedback from new users, and other dapps joining the conversation.

Nonetheless, we’re currently in the midst of completing a code audit on StandardBounties 2.0. This update greatly improves the security guarantees we can make for bounties by having bounties live in separate smart contracts rather than the all-in-one approach used here.

While we cannot confirm the absence of risk, after extensive auditing we believe it is safe to continue employing this version of StandardBounties. We will be migrating to version 2.0 in the coming months, and plan to continue exploring this vulnerability to stay ahead of any potential attackers.

We invite anyone to offer submissions of severe exploits in the code that put funds at risk and offer 10 ETH for submissions of any severe exploits in the code that put funds at risk.

We are very grateful that our bug bounty is producing results, and are excited that Oleksii can be compensated for his successful sleuthing. Moving ahead, we will continue pushing ahead with our efforts to improve our protocol and our product.