Front-running approve() and permit() allows double spending

[c4-submissions]

Lines of code

https://github.com/code-423n4/2023-09-centrifuge/blob/main/src/token/ERC20.sol#L216-L244
https://github.com/code-423n4/2023-09-centrifuge/blob/main/src/Escrow.sol#L22-L27
https://github.com/code-423n4/2023-09-centrifuge/blob/main/src/LiquidityPool.sol#L307-L311

Vulnerability details

Impact

The core issue revolves around the susceptibility to front-running attacks due to the use of the approve function and its analogs without the corresponding increaseAllowance and decreaseAllowance functions.

• Escrow.sol: approve function

  function approve(address token, address spender, uint256 value) external auth {
      SafeTransferLib.safeApprove(token, spender, value);
      emit Approve(token, spender, value);
  }

• ERC20.sol: permit function

  function permit(address owner, address spender, uint256 value, uint256 deadline, bytes memory signature) public {
      // ... (rest of the code)
      allowance[owner][spender] = value;
      emit Approval(owner, spender, value);
  }

• LiquidityPool.sol: approve function

  function approve(address, uint256) public returns (bool) {
      (bool success, bytes memory data) = address(share).call(bytes.concat(msg.data, bytes20(msg.sender)));
      _successCheck(success);
      return abi.decode(data, (bool));
  }

The absence of increaseAllowance and decreaseAllowance methods alongside the use of the approve function leaves the smart contract susceptible to double-spending vulnerabilities facilitated by front-running attacks. These vulnerabilities could potentially lead to unauthorized withdrawals or transfers, which may result in financial loss for users and harm the contract's credibility.

Proof of Concept

Suppose an initial allowance of N tokens exists between an owner and a spender. A user aiming to modify this allowance could inadvertently create a window of opportunity for an attacker to exploit.

1. User Transaction: A user initiates a transaction to change the allowance from N to M.
2. Attacker's Front-Running: Monitoring the mempool, an attacker identifies the user's transaction and sends another transaction with a higher gas price to utilize the remaining N tokens' allowance.
3. User's Allowance Reset: The user's transaction eventually gets mined, resetting the allowance to M.
4. Double Spending: The attacker now has the ability to use an additional M tokens, effectively exploiting the system to use N + M tokens.

Tools Used

manual review

Recommended Mitigation Steps

A unified mitigation strategy involves refactoring the allowance management system to include increaseAllowance and decreaseAllowance functions. This change will prevent the need to reset allowances to zero, thus eliminating the time window that attackers could exploit for double-spending. Specifically, these methods would allow for atomic, relative changes to the allowance, directly addressing the identified vulnerability.

Assessed type

Timing

[c4-pre-sort]

raymondfam marked the issue as sufficient quality report

[c4-pre-sort]

raymondfam marked the issue as duplicate of #145

[c4-judge]

gzeon-c4 marked the issue as unsatisfactory:
Invalid

[c4-judge]

gzeon-c4 marked the issue as unsatisfactory:
Invalid