`ISWHITELISTED` CAN BE USED TO GRIEF OTHERS GAS

[code423n4]

Lines of code

https://github.com/code-423n4/2022-06-putty/blob/3b6b844bc39e897bd0bbb69897f2deff12dc3893/contracts/src/PuttyV2.sol#L670 https://github.com/code-423n4/2022-06-putty/blob/3b6b844bc39e897bd0bbb69897f2deff12dc3893/contracts/src/PuttyV2.sol#L284

Vulnerability details

Impact

The PuttyV2.isWhitelisted is used while filling orders in the scenario where the maker whitelists a specific sender to execute fillOrder. A malicious actor can use the whitelisting feature to waste senders gas by creating a pointless big array and putting the sender address in the end of that array.

Proof of Concept

For example:

• Alice makes a deal with Bob and they agree to take opposite positions on a specific ERC721 token.
• Alice suggests Bob using the whitelisting feature of PuttyV2 and Bob agrees.
• Alice creates an array with a considerable amount of pointless addresses and puts Bobs' address in the end of the whitelist array.
• Bob fills the order successfully but wasted too much gas.

The whitelist array size can be easily manipulated by the order maker (Alice) and the griefing is essentially costless for her. Even if the size is considerably high, the isWhitelisted call may revert because of exceeding the max. block size.

Recommended Mitigation Steps

Three ways to mitigate this were found:

• Capping the maximum amount of whitelisted addresses, and checking that the amount of whitelisted are within the set boundary before filling an order. This will keep the whitelisting method completely on-chain.
• Creating a Merkle Tree with the whitelisted addresses and checking if an user is whitelisted with a signature hash. This will make sense for bigger whitelists but will need to setup a merkle root for each order which has whitelists.
• Using a mixture of both options. For example, if the amount of whitelisted fillers exceeds a certain number, require the contract to use merkle trees instead of an array of addresses. Although this will cover every scenario, it may be much more intricate to properly implement.

[outdoteth]

The transaction cost is shown up front to Bob in whatever wallet he uses. He will immediately be able to see how much he has to pay if there is an excessively large whitelist. So there is no real attack vector here unless Bob is not looking at his transaction before he sends it.

From a game theoretical standpoint, any money that Bob wastes on gas, is money that could have gone towards Alice as a premium instead. So the real one losing out here is Alice (the attacker) not Bob (the supposed victim).

[HickupHH3]

Agree with sponsor's explanation.