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
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
added
3 (High Risk)
Assets can be stolen/lost/compromised directly
bug
Something isn't working
labels
Nov 6, 2022
c4-judge
added
the
primary issue
Highest quality submission among a set of duplicates
label
Nov 15, 2022
dmvt marked the issue as primary issue |
This was referenced Nov 15, 2022
Closed
c4-judge
added
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
downgraded by judge
Judge downgraded the risk level of this issue
and removed
3 (High Risk)
Assets can be stolen/lost/compromised directly
labels
Nov 17, 2022
dmvt changed the severity to 2 (Med Risk) |
kibagateaux marked the issue as sponsor confirmed |
c4-sponsor
added
the
sponsor confirmed
Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
label
Nov 30, 2022
dmvt marked the issue as satisfactory |
liveactionllama marked the issue as duplicate of #355 |
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")
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 to0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE
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.
Tools Used
Vim
Recommended Remediation Steps
receiveTokenOrETH()
should revert if it receives any ETH when the ERC20 token address it not0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE
. For example (the + line is added);The text was updated successfully, but these errors were encountered: