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

Incorrect implementation of ERC-677 #30

Closed
code423n4 opened this issue Apr 13, 2023 · 3 comments
Closed

Incorrect implementation of ERC-677 #30

code423n4 opened this issue Apr 13, 2023 · 3 comments
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working low quality report This report is of especially low quality unsatisfactory does not satisfy C4 submission criteria; not eligible for awards

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2023-04-frankencoin/blob/f86279e76fd9f810d2a25243012e1be4191a547e/contracts/ERC20.sol#L162

Vulnerability details

Impact

The implementation of ERC677 leads to the following issues:

  • It is impossible to use transferAndCall to transfer tokens to a regular user.
  • If the recipient returns false, which means they failed to process the token reception, the tokens will still end up on their contract since there is no check for the result of the onTokenTransfer call, which leads to a loss of the very essence of using this standard.

Proof of Concept

The full implementation of the contract is as follows:
https://github.com/code-423n4/2023-04-frankencoin/blob/f86279e76fd9f810d2a25243012e1be4191a547e/contracts/ERC20.sol#L162

File: contracts\ERC20.sol

162:     function transferAndCall(address recipient, uint256 amount, bytes calldata data) external override returns (bool) {
163:         bool success = transfer(recipient, amount);
164:         if (success){
165:             success = IERC677Receiver(recipient).onTokenTransfer(msg.sender, amount, data);
166:         }
167:         return success;
168:     }

Here we can see that there is no possibility of transferring tokens through this method to a regular user(since a simple user cannot handle the onTokenTransfer call), and the result of the 'onTokenTransfer' call is not checked, leading to a situation where tokens are sent in L163 but not accepted in L165, which may result in their being locked on the recipient's contract.

Links on the resource side:

Tools Used

  • Manual review
  • Hardhat

Recommended Mitigation Steps

  • Fix the implementation or replace it with the current actual standard
@code423n4 code423n4 added 3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working labels Apr 13, 2023
code423n4 added a commit that referenced this issue Apr 13, 2023
@c4-pre-sort c4-pre-sort added the low quality report This report is of especially low quality label Apr 28, 2023
@c4-pre-sort
Copy link

0xA5DF marked the issue as low quality report

@0xA5DF
Copy link

0xA5DF commented Apr 28, 2023

Insignificant impact

@c4-judge
Copy link
Contributor

c4-judge commented May 8, 2023

hansfriese marked the issue as unsatisfactory:
Overinflated severity

@c4-judge c4-judge closed this as completed May 8, 2023
@c4-judge c4-judge added the unsatisfactory does not satisfy C4 submission criteria; not eligible for awards label May 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working low quality report This report is of especially low quality unsatisfactory does not satisfy C4 submission criteria; not eligible for awards
Projects
None yet
Development

No branches or pull requests

4 participants