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

`SnowmanAirdrop::claimSnowman` binds the claim to live `balanceOf(receiver)` — a front-run 1-wei transfer permanently bricks the claim (DoS)

hopeh

Description

To claim, a receiver signs an EIP-712 message over (receiver, amount) and a Merkle proof is checked for the same (receiver, amount) leaf. The intended amount is a FIXED snapshot of what the receiver is entitled to. Instead, claimSnowman (and getMessageHash) recompute amount = i_snow.balanceOf(receiver) from the receiver's LIVE token balance at claim time, and bake that live value into BOTH the signature digest and the Merkle leaf.

Because an ERC20 transfer is permissionless, ANY third party can change balanceOf(receiver) simply by sending the receiver some Snow. The moment they do, the amount recomputed on-chain no longer equals the value committed in the signature/leaf, so _isValidSignature fails (SA__InvalidSignature) or MerkleProof.verify fails (SA__InvalidProof) and the claim reverts. An attacker can front-run any claim (including a claim-on-behalf) with a tiny transfer, so the legitimate receiver can never successfully claim their Snowman.

// SnowmanAirdrop.sol
function getMessageHash(address receiver) public view returns (bytes32) {
uint256 amount = i_snow.balanceOf(receiver); // @> LIVE balance, attacker-movable
return _hashTypedDataV4(keccak256(abi.encode(MESSAGE_TYPEHASH, SnowmanClaim({receiver: receiver, amount: amount}))));
}
​
function claimSnowman(address receiver, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s) external nonReentrant {
// signature checked against getMessageHash(receiver) ...
uint256 amount = i_snow.balanceOf(receiver); // @> LIVE balance again
bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(receiver, amount)))); // @> leaf bound to live balance
if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) revert SA__InvalidProof();
// ...
}

Risk

Likelihood: Medium

  • Griefing requires only that the attacker hold (or buy/earn) some Snow and transfer a dust amount to the target before the claim is mined — a cheap, standard front-run.

  • It applies to the normal claim path (both self-claim and the documented claim-on-behalf), so every legitimate receiver is exposed.

Impact: High

  • Permanent denial of service of the airdrop for any targeted receiver: once their balance is perturbed off the signed/committed amount, every claim with the existing proof + signature reverts. The receiver cannot produce a valid proof for the new balance either, because the Merkle root commits to the original amount. Their Snowman is effectively locked out forever.

Proof of Concept

function test_frontRunTransferBricksClaim() public {
// Alice is a valid recipient; `amount` committed in the tree/signature = her snapshot balance.
// Satoshi will claim on Alice's behalf with Alice's (v, r, s).
​
// Attacker Bob sends Alice 1 extra wei of Snow BEFORE the claim is mined.
vm.prank(bob);
snow.transfer(alice, 1);
​
// Now balanceOf(alice) != the committed amount, so the claim reverts.
vm.prank(satoshi);
vm.expectRevert(); // SA__InvalidSignature or SA__InvalidProof
airdrop.claimSnowman(alice, aliceProof, v, r, s);
}

The claim reverts after a 1-wei transfer, and no future claim with the committed proof can succeed — a permanent, attacker-triggered DoS of the airdrop for that receiver.

Recommended Mitigation

Do not derive the claim amount from a live balance. Commit a FIXED snapshot amount into the Merkle tree (and the signed message) and pass it in as calldata, verifying the proof/signature against that fixed value:

// `amount` is a fixed, snapshotted calldata input committed in the Merkle tree + signed message
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();
// ... verify the signature over the same fixed `amount` ...
}

Then the receiver's live balanceOf can no longer be weaponized to invalidate the claim.

Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge 7 days 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.  ```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!