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

USE OF PAYABLE.TRANSFER() MAY LOCK USER FUNDS #398

Closed
code423n4 opened this issue Nov 10, 2022 · 4 comments
Closed

USE OF PAYABLE.TRANSFER() MAY LOCK USER FUNDS #398

code423n4 opened this issue Nov 10, 2022 · 4 comments
Labels
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 duplicate-369 partial-50 satisfactory Finding meets requirement

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/debtdao/Line-of-Credit/blob/audit/code4rena-2022-11-03/contracts/utils/LineLib.sol#L48

Vulnerability details

Impact

The use of payable.transfer() is heavily frowned upon because it can lead to the locking of funds. The transfer() call requires that the recipient has a payable callback, only provides 2300 gas for its operation.
This means the following cases can cause the transfer to fail:

  • The contract does not have a payable callback
  • The contract’s payable callback spends more than 2300 gas (which is only enough to emit something)
  • The contract is called through a proxy which itself uses up the 2300 gas

If a user falls into one of the above categories, they’ll be unable to receive funds. Inaccessible funds means loss of funds, which is Medium severity.

Proof of Concept

The LineLib.sol sendOutTokenOrETH is being use extensively from other contracts, as this is kind of a library for sending token or ETH from the contract to other receiver contract.

File: LineLib.sol
34:     function sendOutTokenOrETH(
35:       address token,
36:       address receiver,
37:       uint256 amount
38:     )
39:       external
40:       returns (bool)
41:     {
42:         if(token == address(0)) { revert TransferFailed(); }
43:         
44:         // both branches revert if call failed
45:         if(token!= Denominations.ETH) { // ERC20
46:             IERC20(token).safeTransfer(receiver, amount);
47:         } else { // ETH
48:             payable(receiver).transfer(amount);
49:         }
50:         return true;
51:     }

Tools Used

Manual analysis

Recommended Mitigation Steps

Use address.call{value:x}() instead.

@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 10, 2022
code423n4 added a commit that referenced this issue Nov 10, 2022
@c4-judge
Copy link
Contributor

dmvt marked the issue as duplicate of #14

@c4-judge
Copy link
Contributor

dmvt marked the issue as partial-50

@c4-judge c4-judge added the satisfactory Finding meets requirement label Dec 6, 2022
@c4-judge
Copy link
Contributor

c4-judge commented Dec 6, 2022

dmvt marked the issue as satisfactory

@C4-Staff
Copy link
Contributor

liveactionllama marked the issue as duplicate of #369

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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 duplicate-369 partial-50 satisfactory Finding meets requirement
Projects
None yet
Development

No branches or pull requests

3 participants