Santa's List
AI First Flight #3
Beginner FriendlyFoundry
EXP
View results
Previous Next
Submission Details
Severity: high
Valid

checkList has no access control — anyone (not just Santa) can rewrite any address's checked-once status

hopeh

Description

The protocol documents that only Santa may check the list. The checkTwice function enforces this with the onlySanta modifier, but its sibling checkList carries no access control at all:

modifier onlySanta() {
if (msg.sender != i_santa) {
revert SantasList__NotSanta();
}
_;
}
​
// no modifier — callable by anyone
function checkList(address person, Status status) external {
s_theListCheckedOnce[person] = status;
emit CheckedOnce(person, status);
}
​
function checkTwice(address person, Status status) external onlySanta {
if (s_theListCheckedOnce[person] != status) {
revert SantasList__SecondCheckDoesntMatchFirst();
}
s_theListCheckedTwice[person] = status;
emit CheckedTwice(person, status);
}

The README is explicit that checkList is a Santa-only action ("In this contract Only Santa to take the following actions: checkList ... checkTwice"), and checkTwice even reads s_theListCheckedOnce[person] as the trusted baseline it must match. Because checkList is unrestricted, any external account can write an arbitrary Status for any address on the checked-once list — the ledger that is supposed to be under Santa's sole control.

Concretely, an attacker can:

  • Overwrite Santa's determinations: after Santa marks an address NAUGHTY on the once-list, anyone can reset it to NICE/EXTRA_NICE.

  • Grief honest users: set a legitimately EXTRA_NICE user's once-status to NAUGHTY, so when Santa later runs checkTwice(user, EXTRA_NICE) the s_theListCheckedOnce[person] != status guard reverts and the user is denied their token present.

  • Pre-position the once-list to whatever value they want the twice-check to compare against.

The integrity of the naughty/nice ledger — the core state of the protocol — is no longer owned by Santa.

Risk

Impact: High. Access control that the specification explicitly restricts to Santa is missing, so any address can arbitrarily rewrite the checked-once list for any user. This corrupts the trusted baseline that checkTwice depends on and lets an attacker both overwrite Santa's rulings and deny other users their presents.

Likelihood: High. The function is external with no guard; exploitation is a single unprivileged call with attacker-chosen arguments.

Proof of Concept

function test_anyoneCanCheckList() public {
// attacker is NOT santa
address attacker = makeAddr("attacker");
address victim = makeAddr("victim");
​
// 1) Attacker overwrites their own once-status to EXTRA_NICE.
vm.prank(attacker);
santasList.checkList(attacker, SantasList.Status.EXTRA_NICE);
assertEq(uint256(santasList.getNaughtyOrNiceOnce(attacker)), uint256(SantasList.Status.EXTRA_NICE));
​
// 2) Attacker griefs a victim: forces their once-status to NAUGHTY.
vm.prank(attacker);
santasList.checkList(victim, SantasList.Status.NAUGHTY);
assertEq(uint256(santasList.getNaughtyOrNiceOnce(victim)), uint256(SantasList.Status.NAUGHTY));
​
// Now when Santa tries to confirm the victim as EXTRA_NICE, the once/twice
// consistency check reverts and the victim is locked out of their present.
vm.prank(santa);
vm.expectRevert(SantasList.SantasList__SecondCheckDoesntMatchFirst.selector);
santasList.checkTwice(victim, SantasList.Status.EXTRA_NICE);
}

Expected: only Santa can mutate the checked-once list. Actual: any address can set any entry.

Recommended Mitigation

Add the onlySanta modifier to checkList, mirroring checkTwice:

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 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!