Using transferFrom instead of safeTransferFrom #254
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
duplicate
This issue or pull request already exists
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/code-423n4/2022-05-cally/blob/1849f9ee12434038aa80753266ce6a2f2b082c59/contracts/src/Cally.sol#L344
Vulnerability details
Impact
Using transfer and transferFrom instead of their safe alternatives may result in transactions fail silently.
Proof of Concept
Using token transferFrom functions instead of safeTransferFrom (https://github.com/code-423n4/2022-05-cally/blob/1849f9ee12434038aa80753266ce6a2f2b082c59/contracts/src/Cally.sol#L344)
which is highly discouraged and can cause NFTs to be stuck in the case of the transaction not reverting on failed transfers, also, in this case, because the option tokens are burnt in the process (https://github.com/code-423n4/2022-05-cally/blob/1849f9ee12434038aa80753266ce6a2f2b082c59/contracts/src/Cally.sol#L334), calling the function a second time would not mitigate the issue, since the option tokens would be gone. There’s also precedents of this vulnerability as seen here code-423n4/2022-01-trader-joe-findings#12
Tools Used
Manual code review
Recommended Mitigation Steps
We suggest you to check all of your contracts and fix this issue by implementing safeTransfer and safeTransferFrom instead of transfer and transferFrom where applicable.
The text was updated successfully, but these errors were encountered: