Santa's List

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

Any address can permanently block a legitimate user from collecting their present by overwriting their first-check status after Santa's confirmation

Root + Impact

Any address can call the unguarded checkList() to overwrite any victim's s_theListCheckedOnce status at any time — including after Santa has confirmed them via checkTwice(). Once overwritten, the victim's status mappings fall into a mismatched state that collectPresent() cannot satisfy. Santa cannot restore the victim's eligibility without the attacker immediately overwriting it again. The attack costs only gas and can be sustained indefinitely via front-running.

The attack requires the unguarded checkList() (root cause shared with H-1) and the ability to front-run or simply call after Santa's checkTwice() transaction. It requires no capital and no special setup. However, it is a griefing attack with no direct financial gain for the attacker, making sustained execution less likely outside of targeted harassment or competitive scenarios.

Description

  • SantasList is designed so that Santa performs two passes before a user can collect. checkTwice() is the final confirmation, protected by onlySanta. However, because checkList() is missing the onlySanta modifier, any address can overwrite s_theListCheckedOnce for any address at any time — including after Santa has already confirmed them.

// @> no onlySanta modifier — any address can overwrite any victim's first-check status
function checkList(address person, Status status) external {
s_theListCheckedOnce[person] = status;
emit CheckedOnce(person, status);
}

Once the attacker calls checkList(victim, NAUGHTY) after Santa's checkTwice(victim, NICE), the state becomes:

s_theListCheckedOnce[victim] = NAUGHTY // attacker overwrote this
s_theListCheckedTwice[victim] = NICE // Santa set this
  • collectPresent() requires both mappings to match (NICE+NICE or EXTRA_NICE+EXTRA_NICE). The mismatched state satisfies neither branch, causing a permanent revert.

  • Santa cannot rescue the victim. Calling checkTwice(victim, NICE) reverts with SecondCheckDoesntMatchFirst because s_theListCheckedOnce is now NAUGHTY. The only way Santa can avoid the revert is to call checkTwice(victim, NAUGHTY) — but that sets both mappings to NAUGHTY, and collectPresent() still reverts with NotNice.

    This creates an infinite front-running loop where the attacker wins every round:

    Round N:
    Santa: checkList(victim, NICE) + checkTwice(victim, NICE) -> victim confirmed
    Attacker: checkList(victim, NAUGHTY) -> overwrites checkOnce
    Victim: collectPresent() -> reverts NotNice
    Santa: checkTwice(victim, NICE) -> reverts SecondCheckDoesntMatchFirst
    GOTO Round N+1

Risk

Likelihood:

  • Requires only calling the unguarded checkList() — no capital or setup needed

  • Sustainable indefinitely via front-running Santa's checkTwice() transactions

  • Any address can target any confirmed user at any point before they call collectPresent()

Impact:

  • Any legitimately confirmed user can be permanently prevented from collecting their present

  • Santa has no mechanism to restore a victim's eligibility while the attacker is active

  • Targeted harassment of specific users is trivially achievable at gas cost only

Proof of Concept

The following tests demonstrate the grief loop and Santa's inability to rescue the victim:

function test_F7_SantaCannotRescueVictim() public {
// Santa fully confirms victim
vm.startPrank(santa);
santasList.checkList(victim, SantasList.Status.NICE);
santasList.checkTwice(victim, SantasList.Status.NICE);
vm.stopPrank();
vm.warp(santasList.CHRISTMAS_2023_BLOCK_TIME() + 1);
// Attacker overwrites victim's first-check after Santa's confirmation
vm.prank(attacker);
santasList.checkList(victim, SantasList.Status.NAUGHTY);
// Victim cannot collect — checkOnce=NAUGHTY, checkTwice=NICE
vm.prank(victim);
vm.expectRevert(SantasList.SantasList__NotNice.selector);
santasList.collectPresent();
// Santa tries to rescue — checkTwice(NICE) reverts because checkOnce is NAUGHTY
vm.prank(santa);
vm.expectRevert(SantasList.SantasList__SecondCheckDoesntMatchFirst.selector);
santasList.checkTwice(victim, SantasList.Status.NICE);
// Santa forced to call checkTwice(NAUGHTY) — victim is now NAUGHTY on both
vm.prank(santa);
santasList.checkTwice(victim, SantasList.Status.NAUGHTY);
// Victim still cannot collect
vm.prank(victim);
vm.expectRevert(SantasList.SantasList__NotNice.selector);
santasList.collectPresent();
}
function test_F7_InfiniteGriefLoop() public {
for (uint256 round = 1; round <= 3; round++) {
// Santa re-confirms victim each round
vm.startPrank(santa);
santasList.checkList(victim, SantasList.Status.NICE);
santasList.checkTwice(victim, SantasList.Status.NICE);
vm.stopPrank();
// Attacker immediately overwrites
vm.prank(attacker);
santasList.checkList(victim, SantasList.Status.NAUGHTY);
// Victim blocked every round
vm.prank(victim);
vm.expectRevert(SantasList.SantasList__NotNice.selector);
santasList.collectPresent();
assertEq(santasList.balanceOf(victim), 0);
}
}

Recommended Mitigation

The root fix is adding onlySanta to checkList() (see H-1). This eliminates the attacker's ability to overwrite any address's status entirely.

Additionally, consider locking s_theListCheckedOnce for an address once checkTwice() has been called for them, preventing any further overwrites even by Santa after confirmation:

- function checkList(address person, Status status) external {
+ function checkList(address person, Status status) external onlySanta {
s_theListCheckedOnce[person] = status;
emit CheckedOnce(person, status);
}
+ mapping(address => bool) private s_checkedTwiceLocked;
function checkTwice(address person, Status status) external onlySanta {
if (s_theListCheckedOnce[person] != status) {
revert SantasList__SecondCheckDoesntMatchFirst();
}
s_theListCheckedTwice[person] = status;
+ s_checkedTwiceLocked[person] = true;
emit CheckedTwice(person, status);
}
function checkList(address person, Status status) external onlySanta {
+ if (s_checkedTwiceLocked[person]) revert SantasList__AlreadyConfirmed();
s_theListCheckedOnce[person] = status;
emit CheckedOnce(person, status);
}
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 4 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!