Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ExchangeHelpers.sol setMaxAllowance does not mitigate race condition as described #70

Closed
code423n4 opened this issue Nov 15, 2021 · 1 comment
Labels
1 (Low Risk) Assets are not at risk. State handling, function incorrect as to spec, issues with comments bug Something isn't working duplicate This issue or pull request already exists

Comments

@code423n4
Copy link
Contributor

Handle

harleythedog

Vulnerability details

Impact

In ExchangeHelpers.sol, the setMaxAllowance function has the following code:

// Approve 0 first for tokens mitigating the race condition
_token.safeApprove(_spender, 0);
_token.safeApprove(_spender, type(uint256).max);

However, this sequence of approvals does not mitigate the race condition referenced by the comment. Since we are setting the approval amount to 0 and then resetting it to the non-zero value in the same transaction, a front-running attack could still use both approval amounts. The use of safeApprove in SafeERC20 is discouraged when safeIncreaseAllowance/safeDecreaseAllowance are possible (see the comment in the openzeppelin implementation here: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol#:~:text=%7D-,/**,*/,-function%20safeApprove().

I am putting this as a medium severity instead of a high severity, since the function is setting max allowance to the _spender anyways. However, this is still an issue, since _spender may end up using more of the allowance than you think, before you give them max allowance.

Proof of Concept

Referenced code is here: https://github.com/code-423n4/2021-11-nested/blob/main/contracts/libraries/ExchangeHelpers.sol#:~:text=the%20race%20condition-,_token,-.safeApprove(_spender%2C%200

Since the code sets the allowance to 0 and then sets it to a non-zero value in the same transaction (instead of waiting for the zero allowance setting transaction to be mined before setting the non-zero value), the race condition still persists, which is obviously not intended based on the comment in the code.

Tools Used

Manual inspection.

Recommended Mitigation Steps

Instead use safeIncreaseAllowance to set the allowance of the user to the value desired.

@code423n4 code423n4 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working labels Nov 15, 2021
code423n4 added a commit that referenced this issue Nov 15, 2021
@maximebrugel maximebrugel added the duplicate This issue or pull request already exists label Nov 18, 2021
@maximebrugel
Copy link
Collaborator

Now duplicated : #50

@alcueca alcueca added 1 (Low Risk) Assets are not at risk. State handling, function incorrect as to spec, issues with comments and removed 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value labels Dec 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1 (Low Risk) Assets are not at risk. State handling, function incorrect as to spec, issues with comments bug Something isn't working duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

3 participants