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

approve return values not checked & unsafe #247

Open
code423n4 opened this issue Dec 1, 2021 · 1 comment
Open

approve return values not checked & unsafe #247

code423n4 opened this issue Dec 1, 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 sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")

Comments

@code423n4
Copy link
Contributor

Handle

cmichel

Vulnerability details

The ERC20.approve() function returns a boolean value indicating success.
This parameter needs to be checked for success.
Some tokens do not revert if the transfer failed but return false instead.

In addition, some tokens (like USDT L199) do not work when changing the allowance from an existing non-zero allowance value.
They must first be approved by zero and then the actual allowance must be approved.

IERC20(token).safeApprove(address(operator), 0);
IERC20(token).safeApprove(address(operator), amount);

This issue exists for example in AuctionParticipant.purchaseArbitrageTokens:

auctionRewardToken.approve(address(auction), balance);

As well as in UniswapHandler.buyMalt:

rewardToken.approve(address(router), rewardBalance);

Impact

Tokens that don't correctly implement the latest EIP20 spec, by either returning false on failure or reverting if approved from a non-zero value, will be unusable in the protocol as they revert the transaction because of the missing return value.

Recommended Mitigation Steps

We recommend using OpenZeppelin’s SafeERC20 versions with the safeApprove(0) functions that handle the return value check as well as non-standard-compliant tokens.

@code423n4 code423n4 added 1 (Low Risk) Assets are not at risk. State handling, function incorrect as to spec, issues with comments bug Something isn't working labels Dec 1, 2021
code423n4 added a commit that referenced this issue Dec 1, 2021
@0xScotch 0xScotch added the sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") label Dec 8, 2021
@GalloDaSballo
Copy link
Collaborator

Agree with the finding, not sure if this should be raised to medium severity, either way the finding is valid

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 sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Projects
None yet
Development

No branches or pull requests

3 participants