code-423n4 / 2022-11-size-findings

1 stars 0 forks source link

SizeSealed could not work with inflationary/deflationary/rebasing token as base token #235

Closed code423n4 closed 2 years ago

code423n4 commented 2 years ago

Lines of code

https://github.com/code-423n4/2022-11-size/blob/79aa9c01987e57a760521acecfe81b28eab3b313/src/SizeSealed.sol#L96-L105

Vulnerability details

Impact

When creating a new auction, auctionParams.totalBaseAmount amount of token is transferred from seller to SizeSealed and there is a contract balance check balanceAfterTransfer - balanceBeforeTransfer != auctionParams.totalBaseAmount. This check could fail when interacting with inflationary, deflationary or rebasing token. For example with deflationary token, the balance of recipient is not increased by the amount of the transfer (it means balanceAfterTransfer - balanceBeforeTransfer < auctionParams.totalBaseAmount). Because there is no documentation about token behavior restrictions, this issue should be considered

Proof of Concept

https://github.com/code-423n4/2022-11-size/blob/79aa9c01987e57a760521acecfe81b28eab3b313/src/SizeSealed.sol#L96-L105

Tools Used

Manual review

Recommended Mitigation Steps

Should track the real increased balance increment instead of verifying it so that when the auction ends, withdrawals still successfully

uint256 balanceBeforeTransfer = ERC20(auctionParams.baseToken).balanceOf(address(this));
SafeTransferLib.safeTransferFrom(ERC20(auctionParams.baseToken), msg.sender, address(this), auctionParams.totalBaseAmount);
uint256 balanceAfterTransfer = ERC20(auctionParams.baseToken).balanceOf(address(this));
a.params.totalBaseAmount = balanceAfterTransfer - balanceBeforeTransfer;
c4-judge commented 2 years ago

0xean marked the issue as duplicate

c4-judge commented 1 year ago

0xean marked the issue as satisfactory