Closed c4-bot-4 closed 5 months ago
0xSorryNotSorry marked the issue as sufficient quality report
The issue is well demonstrated, properly formatted, contains a coded POC. Marking as HQ.
Also duping any honeypot, FOT, weird ERC20 submissions as well as they have the same balance difference root cause.
0xSorryNotSorry marked the issue as high quality report
0xSorryNotSorry marked the issue as primary issue
I think this is very similar to #1053, so I'm going to comment the same thing :
Imo this is invalid because it is akin to a collateral token that would have infinite minting capability / a compromised owner / etc, there is no impact here that would differ from these simpler situations. There is nothing the protocol can do about it, besides mitigating the damage (and the damage is mitigated by the debt ceilings, hard caps, and liquidity available in the PSM). This is more a governance failure (no term with this collateral token should have been onboarded) than a code failure, I believe the bad debt would still properly be applied in this situation.
eswak (sponsor) disputed
Agree with sponsor comment.
Trumpero marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/2376d9af792584e3d15ec9c32578daa33bb56b43/src/loan/LendingTerm.sol#L813
Vulnerability details
Impact
Malicious actors can leverage the upgradeable ERC20 collateral to manipulate the auction process, enabling them to obtain the entire collateral without meeting their debt obligations. Such exploitation not only jeopardizes the fairness of the lending system but also undermines the security of user funds, eroding trust in the protocol.
Proof of Concept
Since onboarding lending terms with upgradeable ERC20 collaterals aligns with the protocol's behavior, a malicious user can onboard a lending term with an upgradeable ERC20 collateral, take a loan, and retrieve their full collateral in an auction without repaying the debt.
to
with her own address during thetransfer()
operation in the eventmsg.sender == address(term)
. Therefore, it doesn't matter who the bidder is;LendingTerm
will transfer tokens to Alice.bid()
and pays the debt.LendingTerm
callssafeTransfer
in this line to transfer the collateral to the bidder, but the malicious implementation replacesto
with Alice's address instead of the bidder's address.To test the scenario:
Install openzeppelin/contracts-upgradeable ver 4.9.3:
Make a folder/dir named
ninja-tests
in this path:test/uint/
and create below files in it:CollateralProxy.sol:
CollateralToken.sol:
MalERC20ImpForAuction.sol This contract is the malicious implementation which transfers collateral to the attacker instead of the bidder:
MaliciousAuction.t.sol
At the end you should have following files in this path:
test/unit/ninja-tests/
Run the test:
Tools Used
VSCode Foundry
Recommended Mitigation Steps
When transferring collateral to the bidder, it is essential to verify the balance of the bidder both before and after the transfer, ensuring that an adequate amount of collateral has been successfully sent.
Assessed type
Upgradable