Snowman Merkle Airdrop

Medium Severity: Signature Amount Mismatch Allows Claiming With a Different Amount Than Signed

Severity: Medium
Impact: A user can sign a message authorizing a claim for a specific amount of Snow tokens, but later execute the claim with a completely different amount. This undermines the integrity of the off-chain signature and can lead to unauthorized claims of larger quantities than intended.
Affected Contract: SnowmanAirdrop.sol

Summary

The claimSnowman function verifies a signature to prove that the receiver authorized the claim. However, the signed message includes the receiver's Snow balance at the time of signing, yet the actual claim uses the current Snow balance at the moment of the transaction. There is no check that the balance used during claiming matches the balance that was signed. Consequently, a user can sign once for a small balance, later increase their balance, and claim a much larger amount using the same signature.

Vulnerability Details

The signature is created over a digest that includes the receiver's Snow balance as returned by getMessageHash:

The claimSnowman function then recovers the signer and checks that the signer is the receiver, but never uses the signed amount. Instead, it reads the current balance:

There is no requirement that amount == signedAmount. This means the signature only proves that the receiver authorized some claim, not a specific amount. If the user’s balance changes between signing and claiming (e.g., they buy more Snow tokens), they can claim a higher amount with an old signature.

Proof of Concept

The following scenario illustrates the vulnerability:

1. Alice holds 100 Snow. She signs a message (via getMessageHash) authorizing a claim for 100 tokens.

2. Alice later buys 900 more Snow, bringing her balance to 1000.

3. Alice calls claimSnowman with a valid Merkle proof for (Alice, 1000). The proof was presumably generated by the protocol for a snapshot where Alice’s balance was 1000. The signature from step 1 is still valid because it only checks that the signer is Alice, not the amount.

4. The contract uses Alice’s current balance (1000) to compute the leaf and to stake tokens. The old signature (intended for 100) passes the check, and Alice receives 1000 Snowman NFTs instead of 100.

A Foundry test can confirm this by:

• Setting up a Merkle tree with leaves for both (Alice, 100) and (Alice, 1000).

• Having Alice sign a message when her balance is 100.

• Changing her balance to 1000 (by minting more tokens to her).

• Calling claimSnowman with the signature from the 100-case but with the proof for 1000.

• Observing that the transaction succeeds and she receives 1000 NFTs.

Impact

• Integrity of signature-based claims is broken: The signature is supposed to authenticate a specific amount, but it is effectively a blank check for any amount.

• Potential for abuse with balance manipulation: Users can intentionally sign when their balance is low, then inflate it (via purchases or transfers) to claim more NFTs than they originally committed to.

• Undermines the off-chain coordination: The protocol’s design assumes that the signed message locks in a certain distribution amount, but the contract does not enforce this.

Recommended Mitigation

The signed amount must be passed as a parameter to claimSnowman and verified against the actual balance used. The function signature should be changed to include the amount that was signed, and the digest should be reconstructed using that parameter.

For example:

Additionally, the Merkle leaf should be built from the same amount to ensure consistency. This change ensures that the signature is bound to a specific amount and cannot be reused for a different balance.