An malicious user can createAuction and input a malicious ERC20 token contract in his control using auctionParams.quoteToken also on auctionParams.baseToken but that is less likely to happen.
Doing so will allow the malicious user to prevent bidders from calling finalize(), refund(), withdraw() and even cancelBid() functions.
Impact
A malicious user can create an auction and set one of these addresses to a malicious contract in the malicious attacker's control. The attacker allows the user to fill the bid in the auction and then toggles a variable on the malicious contract which will always cause token actions to revert.
The attacker benefits by preventing auction actions from being executing such as finalize(), refund(), withdraw() and even cancelBid(), in addition to locking funds in the contract. This would allow an attacker to prevent the bidders from cancelling or refunding their bids and retrieving any of the ERC20 tokens that are owed to them.
Proof of Concept
A malicious user can set his own malicious ERC token in auctionParams.quoteToken when creating an auction (also possible with auctionParams.baseToken but bidders will less likely to buy an unknown erc20 token).
Assume that bidders will be tempted to get the malicious quoteToken in order to buy (from the created auction) a set amount of a popular baseToken for cheap amount of quoteToken that is an ERC20 controlled malicious token.
Once bidders bid, an attacker "flip the switch" on his controlled ERC20 malicious token contract and revert on all transactions. Doing so, will revert function calls of finalize(), refund(), withdraw() and even cancelBid().
Lines of code
https://github.com/code-423n4/2022-11-size/blob/main/src/SizeSealed.sol#L56 https://github.com/code-423n4/2022-11-size/blob/main/src/interfaces/ISizeSealed.sol#L77
Vulnerability details
Description
An malicious user can
createAuction
and input a malicious ERC20 token contract in his control usingauctionParams.quoteToken
also onauctionParams.baseToken
but that is less likely to happen.Doing so will allow the malicious user to prevent bidders from calling
finalize()
,refund()
,withdraw()
and evencancelBid()
functions.Impact
A malicious user can create an auction and set one of these addresses to a malicious contract in the malicious attacker's control. The attacker allows the user to fill the bid in the auction and then toggles a variable on the malicious contract which will always cause token actions to revert.
The attacker benefits by preventing auction actions from being executing such as
finalize()
,refund()
,withdraw()
and evencancelBid()
, in addition to locking funds in the contract. This would allow an attacker to prevent the bidders from cancelling or refunding their bids and retrieving any of the ERC20 tokens that are owed to them.Proof of Concept
A malicious user can set his own malicious ERC token in
auctionParams.quoteToken
when creating an auction (also possible withauctionParams.baseToken
but bidders will less likely to buy an unknown erc20 token).Assume that bidders will be tempted to get the malicious
quoteToken
in order to buy (from the created auction) a set amount of a popularbaseToken
for cheap amount ofquoteToken
that is an ERC20 controlled malicious token.Once bidders bid, an attacker "flip the switch" on his controlled ERC20 malicious token contract and revert on all transactions. Doing so, will revert function calls of
finalize()
,refund()
,withdraw()
and evencancelBid()
.https://github.com/code-423n4/2022-11-size/blob/main/src/SizeSealed.sol#L56
https://github.com/code-423n4/2022-11-size/blob/main/src/interfaces/ISizeSealed.sol#L77-L78
Recommended Mitigation Steps
Consider whitelisting specific ERC20 token address contracts to prevent users creating auctions with malicious token contracts.