According to the documentation, specific contracts including TempelGoldStaking, DaiGoldAuction, SpiceAuction, and the Gnosis team multisig are intended to be whitelisted using TempleGold::authorizeContract. However, in scenarios where SpiceAuction's auctionConfigs.isTempleGoldAuctionToken is set to false, neither the sender nor the recipient involved in the bidding process is whitelisted. As a result, attempts to execute the bid function will consistently fail due to transfer restrictions, leading to a Denial of Service (DoS) condition for the bidding functionality.
When auctionConfigs.isTempleGoldAuctionToken is set to false, the templeGold token becomes the bid token. The relevant code snippet illustrating this configuration is as follows:
During the execution of the bid function, the contract attempts to transfer bidToken from msg.sender to _recipient. Given that neither party is whitelisted in this configuration, the transfer operation reverts:
The absence of whitelist privileges for SpiceAuction::auctionConfigs.recipient when config.isTempleGoldAuctionToken is set to false results in a DoS condition for the bid function. This issue prevents SpiceAuction from functioning correctly in certain configurations, as the bidding process is essential for the auction mechanism to operate. Moreover, adding recipients to the whitelist as a workaround could potentially compromise the non-transferability principle of the templeGold token, indicating a need for a nuanced solution.
To demonstrate the issue, consider the following test scenario added to SpiceAuction.t.sol:
This test case illustrates that under the specified conditions, the bid function will revert due to the lack of whitelist privileges, effectively demonstrating the DoS vulnerability.
Manual Review
To mitigate the identified vulnerability and ensure the SpiceAuction::bid function operates as intended without causing a Denial of Service (DoS), consider the following approaches:
Option 1: Whitelisting all _recipients
This could involve temporarily authorizing the _recipient address for the duration of the auction or until the bid is processed. Careful implementation is required to ensure that this whitelisting does not inadvertently compromise the non-transferability of the templeGold token outside of legitimate auction activities.
Option 2: Two-Step Transfer Process
Modify the bid function to incorporate a two-step transfer process specifically for scenarios where config.isTempleGoldAuctionToken is set to false. First, transfer the bid tokens from msg.sender to the SpiceAuction contract itself. Then, transfer the tokens from the contract to _recipient. This approach circumvents the need for the recipient to be whitelisted, as the contract is assumed to be authorized for token transfers.
Here's an illustrative code adjustment for the bid function:
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.