Closed code423n4 closed 2 years ago
This adds appreciable overhead in aggregate, prevents fulfillments that involve "burning" some portion of ETH, and would be highly unusual to occur in practice (i.e. including an amount but no recipient address).
Merging with the warden's QA report #123
Lines of code
https://github.com/code-423n4/2022-05-opensea-seaport/blob/main/contracts/lib/Executor.sol#L222-L242 https://github.com/code-423n4/2022-05-opensea-seaport/blob/main/contracts/lib/BasicOrderFulfiller.sol#L962-L966
Vulnerability details
Impact
The protocol doesn't check
to
address when transferring ETH, leading to users may lose ETH accidentally.Proof of Concept
In
_transferEth
, it usecall
to transfer ETH to payableto
address: https://github.com/code-423n4/2022-05-opensea-seaport/blob/main/contracts/lib/Executor.sol#L222-L242In general, all transfer methods (transfer of ERC20, ERC721, ERC1155) will check
to
address should not beaddress(0)
: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol#L232 https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol#L336 https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC1155/ERC1155.sol#L167But
_transferEth
doesn't check theto
address. An offerer will lose ETH when the offerer try to transfer ETH to additional recipients but doesn't set the recipient address correctly: https://github.com/code-423n4/2022-05-opensea-seaport/blob/main/contracts/lib/BasicOrderFulfiller.sol#L962-L966Tools Used
None
Recommended Mitigation Steps
Add a null check for
to
address: