Open sherlock-admin3 opened 3 weeks ago
1 comment(s) were left on this issue during the judging contest.
Honour commented:
Invalid: see comment on #024
I believe this is valid because pool creation is permisionless
Escalate
Invalid issue, calling supply
withdraw
borrow
repay
with tokenId == 0
fall under the category of user mistakes
It is very clear that this functionality was intended to be used in atomic transactions via the multi-call
, so a user can mint and deposit , supply, borrow e.t.c. in one transaction .
It's not sensible for a user with an nft to call either functions with tokenId == 0 as it cannot be guaranteed that their nft was the last minted
Escalate
Invalid issue, calling
supply
withdraw
borrow
repay
withtokenId == 0
fall under the category of user mistakes It is very clear that this functionality was intended to be used in atomic transactions via themulti-call
, so a user can mint and deposit , supply, borrow e.t.c. in one transaction .It's not sensible for a user with an nft to call either functions with tokenId == 0 as it cannot be guaranteed that their nft was the last minted
You've created a valid escalation!
To remove the escalation from consideration: Delete your comment.
You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.
iamnmt
High
NFTPositionManager
's lending functions withparams.tokenId = 0
are vulnerable to front-runningSummary
NFTPositionManager
's lending functions do not take a lending pool as an input parameter will cause the users to interact with a malicious pool when settingparams.tokenId = 0
as an attacker will front-run minting a NFT that linked to a malicious pool and then transfer it to the victim.Root Cause
NFTPositionManager
's lending functions do not take a lending pool as an input parameter.Although the protocol mitigated the front-run attack vector by implementing an ownership check in every lending function. We believe these mitigation are not enough for the users to use the lending functions with
params.tokenId = 0
safelyhttps://github.com/sherlock-audit/2024-06-new-scope/blob/c8300e73f4d751796daad3dadbae4d11072b3d79/zerolend-one/contracts/core/positions/NFTPositionManagerSetters.sol#L46-L49
https://github.com/sherlock-audit/2024-06-new-scope/blob/c8300e73f4d751796daad3dadbae4d11072b3d79/zerolend-one/contracts/core/positions/NFTPositionManagerSetters.sol#L66-L69
https://github.com/sherlock-audit/2024-06-new-scope/blob/c8300e73f4d751796daad3dadbae4d11072b3d79/zerolend-one/contracts/core/positions/NFTPositionManagerSetters.sol#L87-L90
https://github.com/sherlock-audit/2024-06-new-scope/blob/c8300e73f4d751796daad3dadbae4d11072b3d79/zerolend-one/contracts/core/positions/NFTPositionManagerSetters.sol#L107-L110
Internal pre-conditions
A user uses a
NFTPositionManager
lending function withparams.tokenId = 0
.External pre-conditions
No response
Attack Path
The attack vector is viable for every
NFTPositionManager
's lending functions (suppy
,withdraw
,borrow
,repay
), here we will demonstrate an attack path for therepay
function.id = 1
, she supplies collateral and borrows1e18 tokenA
.NFTPositionManager
is her NFT (the NFT withid = 1
), so she callsrepay
withparams.tokenId = 0
.tokenA
and a worthless tokenattackerToken
.1e18 tokenA
directly to the malicious pool.id = 2
, which linked to the malicious pool.id = 2
to supplyattackerToken
as collateral, and then borrow1e18 tokenA
.id = 2
to Alice.id = 2
not the NFT withid = 1
.1e18 tokenA
from the malicious pool and benefits1e18 tokenA
from Alice.Impact
The attacker forced the user to interact with a malicious pool. In case of the
repay
function, the attacker stole all the funds that should be paid to the loan from the user.PoC
Run command:
forge test --match-path test/PoC/PoC.t.sol
Logs:
Mitigation
Add a lending pool to the input parameters of
NFTPositionManager
's lending functions, add check against this lending pool whenparams.tokenId == 0