Attackers can steal any NFT that is currently under sale #42
Labels
3 (High Risk)
Assets can be stolen/lost/compromised directly
bug
Something isn't working
duplicate-6
🤖_03_group
AI based duplicate group recommendation
satisfactory
satisfies C4 submission criteria; eligible for awards
sponsor acknowledged
Technically the issue is correct, but we're not going to resolve it for XYZ reasons
Lines of code
https://github.com/code-423n4/2024-10-coded-estate/blob/main/contracts/codedestate/src/execute.rs#L365-L417
https://github.com/code-423n4/2024-10-coded-estate/blob/main/contracts/codedestate/src/execute.rs#L694-L697
Vulnerability details
Description
Any address that has approval can call
execute.rs#transfer_nft()
successfully because it ensures he has permissions usingcheck_can_send()
. Also if the addressrecipient
has bids in this NFT it will send the funds to the previous ownerWhen NFT is on sell with
token.sell.auto_approve == true
any user can invoke
execute.rs#setbidtobuy()
two times and he will end up with an approval that never expiredBecause the first call will user will transfer the funds to the contract in exchange for getting approval (so he can transfer the NFT).
However, the next call to
setbidtobuy()
will delete the user from thebids
vec and send all the funds back to him. But it doesn't delete the approval in that second transactionUsing this advantage attackers will take the approval and steal NFT with all the funds under it
Impact
Attackers can steal any NFT that is currently under sale.
Tools Used
Manual Review
Recommended Mitigation Steps
File: execute.rs#setbidtobuy() 693: else { 694: // update the approval list (remove any for the same spender before adding) 695: token.bids.retain(|item| item.address != info.sender); + token.approvals.retain(|apr| apr.spender != info.sender); 696: }
Assessed type
Other
The text was updated successfully, but these errors were encountered: