XDZIBEC - XO-Reentrancy attack vulnerability in _revert function

[sherlock-admin]

XDZIBEC

high

XO-Reentrancy attack vulnerability in _revert function

Summary

• The _revert function is vulnerable to reentrancy attacks, means that an attacker can exploit the function to steal funds or data from the contract.

  Vulnerability Detail

  
  function _require(bool condition, uint256 errorCode) pure {
  if (!condition) {
      _revert(errorCode);
  }
  }

/**

• @notice Reverts with errorCode

• @dev The character length is 12, format: "Unitas: errorCode" */ function _revert(uint256 errorCode) pure { assembly { // ASCII 48 = 0 // From right to left let one := add(mod(errorCode, 10), 48) let two := add(mod(div(errorCode, 10), 10), 48) let three := add(mod(div(errorCode, 100), 10), 48) let four := add(mod(div(errorCode, 1000), 10), 48)

  let err := shl(
      // 256 - 8 * 12
      160,
      add(
          shl(
              // 4 spaces
              32,
              // "Unitas: "
              0x556e697461733a20
          ),
          add(add(add(
              one,
              shl(8, two)),
              shl(16, three)),
              shl(24, four)
          )
      )
  )
  
  // bytes4(keccak256("Error(string)"))
  mstore(0x0, 0x08c379a000000000000000000000000000000000000000000000000000000000)
  // Offset
  mstore(0x04, 0x0000000000000000000000000000000000000000000000000000000000000020)
  // Character length
  mstore(0x24, 12)
  // Message
  mstore(0x44, err)
  
  // 4 + 32 + 32 + 32
  revert(0, 100)

  } }

/**

- The vulnerability is in the `_revert` function, the problem is that the `revert` `opcode` does not disable the ability for other contracts to `call` the current contract  means that if an attacker can call the `_revert` function while the contract is in a `vulnerable` state, the attacker can then call other contracts and steal funds or data from the contract, this version of the `_revert` function uses the `unreachable` opcode to prevent other contracts from being called after the `revert` opcode is executed. This makes the contract immune to `reentrancy` attacks.
## Impact
- An attacker could exploit the `reentrancy` attack vulnerability in the `_revert` function:
    - The attacker sends some` funds` to the contract.
    - The attacker calls the `_revert` function.
    - The` _revert` function calls the `revert opcode`, which `reverts` the` transaction `and returns the` funds` to the `sender`.
    - The attacker calls another contract function that is `owned` by the attacker.
    - The second contract function `calls` back to the `_revert` function.
    - The `_revert `function is called again, even though it has already been called.
    - The attacker can now `steal` the `funds` that were returned to the sender in `step 3`.
## Code Snippet
- https://github.com/sherlock-audit/2023-04-unitasprotocol/blob/main/Unitas-Protocol/src/utils/Errors.sol#L7C1-L59C4
## Tool used

Manual Review

## Recommendation
- to fix the issue in the `_revert` function, you can use the `unreachable opcode`. The unreachable opcode tells the `Ethereum` Virtual Machine that the current execution path is unreachable, and the `EVM` will not continue executing any instructions after the `unreachable opcode`.