Snowman Merkle Airdrop
AI First Flight #10
Beginner FriendlyFoundrySolidityNFT
EXP
View results
Previous Next
Submission Details
Severity: medium
Valid

SnowmanAirdrop::getMessageHash - Using live Snow balance in EIP-712 digest allows anyone to invalidate a receiver's delegated claim signature by transferring tokens to them

ciphermagic

Root + Impact

Description

  • SnowmanAirdrop::getMessageHash() constructs the EIP-712 digest by reading i_snow.balanceOf(receiver) at call time. A receiver signs this digest to authorize a third party to claim on their behalf.

  • Because the digest encodes the receiver's live Snow balance, any change to that balance — including a transfer of as little as 1 wei of Snow by a third party — produces a different digest. The previously valid signature no longer matches the new digest, causing _isValidSignature() to return false and the claim to revert with SA__InvalidSignature.

function getMessageHash(address receiver) public view returns (bytes32) {
// @> amount is read from live state — not locked at signing time
uint256 amount = i_snow.balanceOf(receiver);
return _hashTypedDataV4(
keccak256(abi.encode(MESSAGE_TYPEHASH, SnowmanClaim({receiver: receiver, amount: amount})))
);
}

Risk

Likelihood:

  • Snow is a standard ERC20 token; any address can freely transfer tokens to any receiver

  • An attacker needs only 1 wei of Snow and a single transfer transaction to execute the attack

  • The attack can be repeated indefinitely every time the receiver re-signs

Impact:

  • An attacker can grief any receiver who has published a delegated claim signature by sending them 1 Snow token, forcing them to re-sign

  • The attacker can repeat this continuously, making delegated claiming practically unusable for targeted recipients

  • Receivers without the ability to front-run the attacker are permanently denied gasless claiming

Proof of Concept

The following Foundry test demonstrates the griefing attack. An attacker transfers
one Snow token to the receiver after the receiver has signed their delegation message.
The test asserts that the digest returned by getMessageHash() before and after the
transfer are different, confirming that any in-flight delegated claim will revert with
SA__InvalidSignature after even a 1 wei balance change.

function test_balanceChangeInvalidatesSignature() public {
address receiver = 0x328809Bc894f92807417D2dAD6b7C998c1aFdac6;
address attacker = makeAddr("attacker");
​
// receiver signs the digest based on their current balance of 1
bytes32 digestAtSigning = airdrop.getMessageHash(receiver);
​
// attacker sends 1 Snow to receiver, changing their balance to 2
deal(address(snow), attacker, 1);
vm.prank(attacker);
snow.transfer(receiver, 1);
​
// digest has changed — receiver's original signature is now invalid
bytes32 digestAfterTransfer = airdrop.getMessageHash(receiver);
assertNotEq(digestAtSigning, digestAfterTransfer);
​
// any claim attempt using the original signature will revert SA__InvalidSignature
}

Recommended Mitigation

The fix decouples the signed amount from the receiver's live balance by accepting
amount as an explicit calldata parameter. The receiver signs a fixed value at
delegation time; the contract then verifies the signature against that fixed value
rather than re-reading state. A balance sufficiency check replaces the equality
assumption, ensuring the receiver still holds enough Snow to cover the claimed amount
while making the digest immune to any subsequent transfers.

Pass amount as an explicit parameter rather than reading it from live state, so the signed value is locked at signing time:

function claimSnowman(
address receiver,
+ uint256 amount,
bytes32[] calldata merkleProof,
uint8 v, bytes32 r, bytes32 s
) external nonReentrant {
if (receiver == address(0)) { revert SA__ZeroAddress(); }
- if (i_snow.balanceOf(receiver) == 0) { revert SA__ZeroAmount(); }
+ if (i_snow.balanceOf(receiver) < amount || amount == 0) { revert SA__ZeroAmount(); }
​
- if (!_isValidSignature(receiver, getMessageHash(receiver), v, r, s)) {
+ if (!_isValidSignature(receiver, getMessageHash(receiver, amount), v, r, s)) {
revert SA__InvalidSignature();
}
- uint256 amount = i_snow.balanceOf(receiver);
// ...rest unchanged
}
​
- function getMessageHash(address receiver) public view returns (bytes32) {
- uint256 amount = i_snow.balanceOf(receiver);
+ function getMessageHash(address receiver, uint256 amount) public view returns (bytes32) {
return _hashTypedDataV4(
keccak256(abi.encode(MESSAGE_TYPEHASH, SnowmanClaim({receiver: receiver, amount: amount})))
);
}
Updates

Lead Judging Commences

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

[M-01] DoS to a user trying to claim a Snowman

# Root + Impact ## Description * Users will approve a specific amount of Snow to the SnowmanAirdrop and also sign a message with their address and that same amount, in order to be able to claim the NFT * Because the current amount of Snow owned by the user is used in the verification, an attacker could forcefully send Snow to the receiver in a front-running attack, to prevent the receiver from claiming the NFT.&#x20; ```Solidity function getMessageHash(address receiver) public view returns (bytes32) { ... // @audit HIGH An attacker could send 1 wei of Snow token to the receiver and invalidate the signature, causing the receiver to never be able to claim their Snowman uint256 amount = i_snow.balanceOf(receiver); return _hashTypedDataV4( keccak256(abi.encode(MESSAGE_TYPEHASH, SnowmanClaim({receiver: receiver, amount: amount}))) ); ``` ## Risk **Likelihood**: * The attacker must purchase Snow and forcefully send it to the receiver in a front-running attack, so the likelihood is Medium **Impact**: * The impact is High as it could lock out the receiver from claiming forever ## Proof of Concept The attack consists on Bob sending an extra Snow token to Alice before Satoshi claims the NFT on behalf of Alice. To showcase the risk, the extra Snow is earned for free by Bob. ```Solidity function testDoSClaimSnowman() public { assert(snow.balanceOf(alice) == 1); // Get alice's digest while the amount is still 1 bytes32 alDigest = airdrop.getMessageHash(alice); // alice signs a message (uint8 alV, bytes32 alR, bytes32 alS) = vm.sign(alKey, alDigest); vm.startPrank(bob); vm.warp(block.timestamp + 1 weeks); snow.earnSnow(); assert(snow.balanceOf(bob) == 2); snow.transfer(alice, 1); // Alice claim test assert(snow.balanceOf(alice) == 2); vm.startPrank(alice); snow.approve(address(airdrop), 1); // satoshi calls claims on behalf of alice using her signed message vm.startPrank(satoshi); vm.expectRevert(); airdrop.claimSnowman(alice, AL_PROOF, alV, alR, alS); } ``` ## Recommended Mitigation Include the amount to be claimed in both `getMessageHash` and `claimSnowman` instead of reading it from the Snow contract. Showing only the new code in the section below ```Python function claimSnowman(address receiver, uint256 amount, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s) external nonReentrant { ... bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(receiver, amount)))); if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) { revert SA__InvalidProof(); } // @audit LOW Seems like using the ERC20 permit here would allow for both the delegation of the claim and the transfer of the Snow tokens in one transaction i_snow.safeTransferFrom(receiver, address(this), amount); // send ... } ```

Support

FAQs

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

Give us feedback!