Snowman Merkle Airdrop

AI First Flight #10
Beginner FriendlyFoundrySolidityNFT
EXP
View results
Submission Details
Severity: low
Valid

Attacker can globally block earnSnow by frequently calling buySnow

Root + Impact

The Snow contract implements a cooldown mechanism for earning tokens via the s_earnTimer variable. However, this variable is a global state variable rather than a per-user mapping. Furthermore, it is updated in both the earnSnow and buySnow functions. Because any user can call buySnow at any time, an attacker can intentionally reset the timer for the entire protocol, preventing any other user from successfully calling earnSnow.

Description

The earnSnow function checks if (s_earnTimer != 0 && block.timestamp < (s_earnTimer + 1 weeks)). If this condition is true, the transaction reverts. Because buySnow also sets s_earnTimer = block.timestamp, a malicious actor can perform a "Denial of Service" (DoS) attack on the protocol's "free earn" feature by:

  1. Waiting for nearly a week to pass since the last activity.

  2. Executing a buySnow transaction with a minimal amount (e.g., 1 wei) of ETH/WETH.

  3. This resets s_earnTimer to the current time, forcing everyone else to wait another full week to be eligible for earnSnow.

This can be automated via a script to permanently lock the earn feature.

// src/Snow.sol
function buySnow(uint256 amount) external payable canFarmSnow {
// ... (minting logic)
@> s_earnTimer = block.timestamp;
emit SnowBought(msg.sender, amount);
}
function earnSnow() external canFarmSnow {
@> if (s_earnTimer != 0 && block.timestamp < (s_earnTimer + 1 weeks)) {
revert S__Timer();
}
_mint(msg.sender, 1);
@> s_earnTimer = block.timestamp;
}

Risk

Likelihood:High

  • The attack is extremely inexpensive (buying 1 wei of Snow token costs almost nothing).

  • The vulnerability is baked into the core logic of the contract's primary state variable.

Impact:

  • Legitimate users are indefinitely prevented from earning "free" tokens as promised by the protocol documentation.

  • The protocol's distribution becomes unfair, favoring only those who buy tokens, which may deviate from the project's tokenomics goals

Proof of Concept

The PoC simulates a timeline where UserA earns snow, setting the timer. After 1 week passes, UserB should be eligible to earn snow. However, an attacker calls buySnow just before UserB can act. This resets the global s_earnTimer, causing UserB's subsequent earnSnow call to revert with S__Timer.

function test_poc_GlobalTimerDoS() public {
// 1. UserA earns snow, starting the global timer
vm.prank(userA);
snow.earnSnow();
// 2. Almost one week passes
vm.warp(block.timestamp + 1 weeks);
// 3. Attacker buys 1 snow token right before UserB can earn
// This resets the global s_earnTimer for everyone
vm.startPrank(attacker);
deal(attacker, 1 ether);
snow.buySnow{value: 1 ether}(1);
vm.stopPrank();
// 4. UserB tries to earn snow (now that 1 week has passed since UserA's call)
// But it fails because the attacker reset the global timer
vm.prank(userB);
vm.expectRevert(Snow.S__Timer.selector);
snow.earnSnow();
}

Recommended Mitigation

The cooldown should be tracked on a per-user basis using a mapping. This ensures that one user's activity (buying or earning) does not affect another user's eligibility. Additionally, if the intention is only to limit the "free earn" rate, buySnow should not update the earnSnow timer at all.

+ mapping(address => uint256) private s_userEarnCooldown;
function earnSnow() external canFarmSnow {
- if (s_earnTimer != 0 && block.timestamp < (s_earnTimer + 1 weeks)) {
+ if (s_userEarnCooldown[msg.sender] != 0 && block.timestamp < (s_userEarnCooldown[msg.sender] + 1 weeks)) {
revert S__Timer();
}
_mint(msg.sender, 1);
- s_earnTimer = block.timestamp;
+ s_userEarnCooldown[msg.sender] = block.timestamp;
}
// Also remove s_earnTimer = block.timestamp from buySnow if it's not meant to restrict buying.
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 24 hours ago
Submission Judgement Published
Validated
Assigned finding tags:

[L-02] Global Timer Reset in Snow::buySnow Denies Free Claims for All Users

## Description: The `Snow::buySnow` function contains a critical flaw where it resets a global timer `(s_earnTimer)` to the current block timestamp on every invocation. This timer controls eligibility for free token claims via `Snow::earnSnow()`, which requires 1 week to pass since the last timer reset. As a result: Any token purchase `(via buySnow)` blocks all free claims for all users for 7 days Malicious actors can permanently suppress free claims with micro-transactions Contradicts protocol documentation promising **"free weekly claims per user"** ## Impact: * **Complete Denial-of-Service:** Free claim mechanism becomes unusable * **Broken Protocol Incentives:** Undermines core user acquisition strategy * **Economic Damage:** Eliminates promised free distribution channel * **Reputation Harm:** Users perceive protocol as dishonest ```solidity function buySnow(uint256 amount) external payable canFarmSnow { if (msg.value == (s_buyFee * amount)) { _mint(msg.sender, amount); } else { i_weth.safeTransferFrom(msg.sender, address(this), (s_buyFee * amount)); _mint(msg.sender, amount); } @> s_earnTimer = block.timestamp; emit SnowBought(msg.sender, amount); } ``` ## Risk **Likelihood**: • Triggered by normal protocol usage (any purchase) • Requires only one transaction every 7 days to maintain blockage • Incentivized attack (low-cost disruption) **Impact**: • Permanent suppression of core protocol feature • Loss of user trust and adoption • Violates documented tokenomics ## Proof of Concept **Attack Scenario:** Permanent Free Claim Suppression * Attacker calls **buySnow(1)** with minimum payment * **s\_earnTimer** sets to current timestamp (T0) * All **earnSnow()** calls revert for **next 7 days** * On day 6, attacker repeats **buySnow(1)** * New timer reset (T1 = T0+6 days) * Free claims blocked until **T1+7 days (total 13 days)** * Repeat step **4 every 6 days → permanent blockage** **Test Case:** ```solidity // Day 0: Deploy contract snow = new Snow(...); // s_earnTimer = 0 // UserA claims successfully snow.earnSnow(); // Success (first claim always allowed) // Day 1: UserB buys 1 token snow.buySnow(1); // Resets global timer to day 1 // Day 2: UserA attempts claim snow.earnSnow(); // Reverts! Requires day 1+7 = day 8 // Day 7: UserC buys 1 token (day 7 < day 1+7) snow.buySnow(1); // Resets timer to day 7 // Day 8: UserA retries snow.earnSnow(); // Still reverts! Now requires day 7+7 = day 14 ``` ## Recommended Mitigation **Step 1:** Remove Global Timer Reset from `buySnow` ```diff function buySnow(uint256 amount) external payable canFarmSnow { // ... existing payment logic ... - s_earnTimer = block.timestamp; emit SnowBought(msg.sender, amount); } ``` **Step 2:** Implement Per-User Timer in `earnSnow` ```solidity // Add new state variable mapping(address => uint256) private s_lastClaimTime; function earnSnow() external canFarmSnow { // Check per-user timer instead of global if (s_lastClaimTime[msg.sender] != 0 && block.timestamp < s_lastClaimTime[msg.sender] + 1 weeks ) { revert S__Timer(); } _mint(msg.sender, 1); s_lastClaimTime[msg.sender] = block.timestamp; // Update user-specific timer emit SnowEarned(msg.sender, 1); // Add missing event } ``` **Step 3:** Initialize First Claim (Constructor) ```solidity constructor(...) { // Initialize with current timestamp to prevent immediate claims s_lastClaimTime[address(0)] = block.timestamp; } ```

Support

FAQs

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

Give us feedback!