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

Unauthorized Token Transfer Due To Bad Approval Mechanism #349

Closed
c4-submissions opened this issue Sep 7, 2023 · 5 comments
Closed

Unauthorized Token Transfer Due To Bad Approval Mechanism #349

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

Comments

@c4-submissions
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2023-09-ondo/blob/main/contracts/usdy/rUSDY.sol#L277
https://github.com/code-423n4/2023-09-ondo/blob/main/contracts/usdy/rUSDY.sol#L310
https://github.com/code-423n4/2023-09-ondo/blob/main/contracts/usdy/rUSDY.sol#L493

Vulnerability details

Impact

The identified issue pertains to the token transfer mechanism within a smart contract. Specifically, the contract allows a user to approve themselves for a certain amount of tokens without actually deducting this amount from their balance. Subsequently, when the user (or an approved spender) initiates a transfer, the contract deducts the allowance but fails to check and deduct the actual balance of the sender. This flaw allows any user to effectively mint tokens out of thin air, leading to a severe security vulnerability.

Proof of Concept

function approve(address _spender, uint256 _amount) public returns (bool) {
_approve(msg.sender, _spender, _amount);
return true;
}

an attacker calls approve as he sets _spender as his address

function _approve(
address _owner,
address _spender,
uint256 _amount
) internal whenNotPaused {
require(_owner != address(0), "APPROVE_FROM_ZERO_ADDRESS");
require(_spender != address(0), "APPROVE_TO_ZERO_ADDRESS");

allowances[_owner][_spender] = _amount;
emit Approval(_owner, _spender, _amount);
}

thus allowances[attacker][attacker] = _amount;
but _amount is not deducted from _owner's balance

function transferFrom(
address _sender,
address _recipient,
uint256 _amount
) public returns (bool) {
uint256 currentAllowance = allowances[_sender][msg.sender];
require(currentAllowance >= _amount, "TRANSFER_AMOUNT_EXCEEDS_ALLOWANCE");

_transfer(_sender, _recipient, _amount);
_approve(_sender, msg.sender, currentAllowance - _amount);
return true;
}

when he calls transferFrom currentAllowance would be allowances[attacker][attacker] which is _amount,
the _amount s transfered to _recipient, which can be his address as well,
_approve deduct the _amount from the allowance, means allowances[attacker][attacker] = 0,
while it was not deducted from _owner's balance, thus the _amount was sent from the contract's balance.

Tools Used

Manual review

Recommended Mitigation Steps

Modify the transferFrom function to not only check the allowance but also ensure that the sender has a sufficient balance. Deduct the transferred amount from the sender's balance.

Assessed type

Token-Transfer

@c4-submissions c4-submissions added 3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working labels Sep 7, 2023
c4-submissions added a commit that referenced this issue Sep 7, 2023
@raymondfam
Copy link

It's checked here:

https://github.com/code-423n4/2023-09-ondo/blob/main/contracts/usdy/rUSDY.sol#L524-L528

    uint256 currentSenderShares = shares[_sender];
    require(
      _sharesAmount <= currentSenderShares,
      "TRANSFER_AMOUNT_EXCEEDS_BALANCE"
    );

@c4-pre-sort
Copy link

raymondfam marked the issue as low quality report

@c4-pre-sort c4-pre-sort added low quality report This report is of especially low quality primary issue Highest quality submission among a set of duplicates labels Sep 8, 2023
@c4-pre-sort
Copy link

raymondfam marked the issue as primary issue

@c4-pre-sort c4-pre-sort added duplicate-102 and removed primary issue Highest quality submission among a set of duplicates labels Sep 10, 2023
@c4-pre-sort
Copy link

raymondfam marked the issue as duplicate of #102

@c4-judge
Copy link
Contributor

kirk-baird marked the issue as unsatisfactory:
Invalid

@c4-judge c4-judge added the unsatisfactory does not satisfy C4 submission criteria; not eligible for awards label Sep 19, 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 duplicate-102 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