TempleGold
TempleDAO
Foundry
25,000 USDC
View results
Previous Next
Submission Details
Severity: medium
Invalid

[H-1] DaiGoldAuction::startAuction can be called repeatedly right after contract deployment, leading to tokens being stuck permanently.

0xcontrol

[H-1] DaiGoldAuction::startAuction can be called repeatedly right after contract deployment, leading to tokens being stuck permanently.

Summary
The startAuction() function in DaiGoldAuction can be called repeatedly right after the contract deployment, leading to tokens being stuck permanently. This occurs due to a lack of proper validation checks on the initial state, allowing the function to bypass necessary cooldown periods and start auctions prematurely.

Code Reference:

function startAuction() external override {
if (auctionStarter != address(0) && msg.sender != auctionStarter) { revert CommonEventsAndErrors.InvalidAccess(); }
EpochInfo storage prevAuctionInfo = epochs[_currentEpochId];
if (!prevAuctionInfo.hasEnded()) { revert CannotStartAuction(); }
AuctionConfig storage config = auctionConfig;
/// @notice last auction end time plus wait period
if (_currentEpochId > 0 && (prevAuctionInfo.endTime + config.auctionsTimeDiff > block.timestamp)) {
revert CannotStartAuction();
}
_distributeGold();
uint256 totalGoldAmount = nextAuctionGoldAmount;
nextAuctionGoldAmount = 0;
uint256 epochId = _currentEpochId = _currentEpochId + 1;
if (totalGoldAmount < config.auctionMinimumDistributedGold) { revert LowGoldDistributed(totalGoldAmount); }
​
EpochInfo storage info = epochs[epochId];
info.totalAuctionTokenAmount = totalGoldAmount;
uint128 startTime = info.startTime = uint128(block.timestamp) + config.auctionStartCooldown;
uint128 endTime = info.endTime = startTime + AUCTION_DURATION;
​
emit AuctionStarted(epochId, msg.sender, startTime, endTime, totalGoldAmount);
}

Vulnerability Details:
The startAuction() function does not validate the initial state right after contract deployment, leading to the possibility of starting multiple auctions in quick succession, without the onlyElevatedAccess first calling setAuctionConfig. The function startAuction() checks if the previous auction has ended and ensures a cooldown period between auctions. However, these checks can be bypassed right after deployment because the initial state does not have a previous auction, allowing the function to start new auctions without proper cooldowns.

  • In the DaiGoldAuction contract after deployment, the protocol is supposed to first set the auction config even before a user can call startAuction(), but because of the lack of check in the contract any user can start calling startAuction right after contract deployment

Impact:
Allowing repeated calls to startAuction() immediately after deployment can have severe consequences such as token been locked up in the contract forever and also contract functionality been compromised, making the contract unusable.

Proof of Concept:
The lack of validation for the initial state allows repeated calls to startAuction() as demonstrated in the following scenario:

  1. Deploy the DaiGoldAuction contract.

  2. do not call the setAuctionConfig at this moment

  3. Call startAuction() repeatedly without waiting for the cooldown periods.

Recommended Mitigation:
To prevent repeated calls to startAuction() right after deployment, it is recommended to implement additional validation checks to handle the initial state appropriately. This can include setting up a duration before the first auction can start

Updates

Lead Judging Commences

inallhonesty Lead Judge 12 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

`startAuction` the second the DaiGoldAuction is deployed can be used to DOS the contract

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.