Send (SDT) Bug Bounty Report

Our bug bounty program is officially closed as we prepare to deploy the SDT Smart Contracts later this week. We would like to thank those from the community who participated by trying to hack our code.

One moderate severity vulnerability was found and is described below, including the new Github commit.

Moderate report #1

Original report:

There exists an integer overflow via the fundEscrow function in SendToken.sol. This allows an attacker to steal an infinite amount of money from the escrow system by setting their own payment as having been paid, despite transferring a nominal amount of money.

Reproduction Steps

1. Create an escrow via the createEscrow with the following parameters:
   _tokens: 2**256–1, _fee: 2.
2. Make a call to fundEscrow with the same values for _tokens and _fee.
3. Observe that an unsafe addition is performed on line 143:
   uint256 total = _tokens + _fee;
   transfer(escrow, total);
4. This will result in a total amount of 1 being transferred due to an integer overflow.
5. In fund, the escrow will be marked as paid.
6. From here, an attacker can make a call to release to steal the entire amount of money held in the escrow system.

Impact

This vulnerability allows an attacker to steal all money in the escrow system.

Suggested Remediation

Use safe addition when performing sensitive actions.

Team analysis:

It’s possible to mark escrow as paid if the pair (value, fee) causes an overflow, however, there are only 2 functions that will allow the attacker to withdraw tokens from escrow:

release method: In this method there are 2 transfers: token.transfer(_recipient, lock.value) and token.transfer(msg.sender, lock.fee); since value + fee is higher than 2**256 it’s impossible to have a successful execution of the release method.

Github
token.transfer(_recipient, lock.value);
if (lock.fee > 0) {
token.transfer(msg.sender, lock.fee);
}

claim method: In this method there is only one transfer: token.transfer(msg.sender, lock.value + lock.fee); since this is an unhandled sum it will produce exactly the same overflow value caused during the escrow fund. So, the amount withdrawn from the contract will be exactly the same amount used to fund the escrow.

Github
token.transfer(msg.sender, lock.value + lock.fee);

Therefore this doesn’t seem to be a exploitable function, and the effect of the overflow would only affect the attacker creating an unreleasable (but claimable) escrow record.

Even though this doesn’t seem to affect anyone besides the attacker with current contracts, this has been categorized as a moderate severity vulnerability because escrow contract is meant to be upgradeable and this could restrict the scope or introduce errors in future updates.

Actions taken:

Fixed on commit 13e08626c296b04c7538ce1f26f353a3a114757f.

Thanks again to those of you who participated. The SDT Smart Contracts will launch on June 1. We invite you to join us for further updates on Telegram.