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

Funds can be added and not accrue as collateral #89

Closed
code423n4 opened this issue Nov 6, 2022 · 5 comments
Closed

Funds can be added and not accrue as collateral #89

code423n4 opened this issue Nov 6, 2022 · 5 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 downgraded by judge Judge downgraded the risk level of this issue duplicate-355 satisfactory Finding meets requirement 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

Lines of code

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

Vulnerability details

Impact

receiveTokenOrETH() is used throughout LineOfCredit.sol (e.g. addCredit(), increaseCredit()) and Escrow.sol (via EscrowLib.sol) to receive funds in the form of ETH or ERC20 tokens.

The receiveTokenOrETH() requires the caller to send ETH with the token address set to 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE OR send ERC20 tokens with the token address set to an approved token (decided by the arbiter).

The issue is that the caller can send ETH with the token not set to 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE resulting in both ETH and ERC20 being deposited at the same time.

This causes issues with accounting across the project and the loss of ETH if it is sent alongside a supported ERC20 token.

Proof of Concept

The foundry test below added to Escrow.t.sol demonstrates that you can send ETH alongside an ERC20 token. The ETH is accepted but not accounted for as only the supported ERC20 token address (that is not all E’s) is added as collateral.

function test_can_send_eth_and_token() public {
  uint borrowerBalance = borrower.balance;
  uint borrowerTokenBalance = supportedToken1.balanceOf(borrower);
  uint escrowBalance = address(escrow).balance;
  escrow.addCollateral{value: mintAmount}(mintAmount, address(supportedToken1));
  assertEq(
    borrowerBalance,
    borrower.balance + mintAmount,
    "borrower should have decreased with collateral deposit"
  );
  assertEq(
    borrowerTokenBalance,
    supportedToken1.balanceOf(borrower) + mintAmount,
    "borrower should have decreased token collateral"
  );
  assertEq(
    escrowBalance,
    address(escrow).balance - mintAmount,
    "escrow should have increased with collateral deposit"
  );
}

Tools Used

Vim

Recommended Remediation Steps

receiveTokenOrETH() should revert if it receives any ETH when the ERC20 token address it not 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE. For example (the + line is added);

function receiveTokenOrETH(
  address token,
  address sender,
  uint256 amount
)
  external
  returns (bool)
{
    if(token == address(0)) { revert TransferFailed(); }
    if(token != Denominations.ETH) { // ERC20
+       require(msg.value <= 0, "Don't send ETH on ERC20 transfers");
        IERC20(token).safeTransferFrom(sender, address(this), amount);
    } else { // ETH
        if(msg.value < amount) { revert TransferFailed(); }
    }
    return true;
}
@code423n4 code423n4 added 3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working labels Nov 6, 2022
code423n4 added a commit that referenced this issue Nov 6, 2022
@c4-judge c4-judge added the primary issue Highest quality submission among a set of duplicates label Nov 15, 2022
@c4-judge
Copy link
Contributor

dmvt marked the issue as primary issue

@c4-judge
Copy link
Contributor

dmvt changed the severity to 2 (Med Risk)

@c4-sponsor
Copy link

kibagateaux marked the issue as sponsor confirmed

@c4-judge
Copy link
Contributor

c4-judge commented Dec 6, 2022

dmvt marked the issue as satisfactory

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

liveactionllama marked the issue as duplicate of #355

@C4-Staff C4-Staff added duplicate-355 and removed primary issue Highest quality submission among a set of duplicates labels Dec 20, 2022
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 downgraded by judge Judge downgraded the risk level of this issue duplicate-355 satisfactory Finding meets requirement 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

4 participants