Santa's List

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

Any address can overwrite the first-pass status after Santa approval and permanently block present claims

Root: checkList() is missing the onlySanta modifier, allowing arbitrary users to overwrite s_theListCheckedOnce even after Santa has already completed both checks. Impact: an attacker can invalidate an approved user’s claim path and prevent them from collecting their present.

Description

  • The intended behavior is that Santa performs a first review through checkList() and a second review through checkTwice(). Once both checks match and a user is marked NICE or EXTRA_NICE, that user should remain eligible to collect their present after the Christmas time gate.

  • The issue is that checkList() is unrestricted and can be called by any address, even after Santa has already completed the second check. Since collectPresent() requires both stored statuses to match the expected value, a third party can overwrite s_theListCheckedOnce[user] after Santa approval and make the user fail the eligibility check.

function checkList(address person, Status status) external {
@> s_theListCheckedOnce[person] = status;
emit CheckedOnce(person, status);
}
function collectPresent() external {
...
if (
@> s_theListCheckedOnce[msg.sender] == Status.NICE &&
@> s_theListCheckedTwice[msg.sender] == Status.NICE
) {
_mintAndIncrement();
return;
} else if (
@> s_theListCheckedOnce[msg.sender] == Status.EXTRA_NICE &&
@> s_theListCheckedTwice[msg.sender] == Status.EXTRA_NICE
) {
_mintAndIncrement();
i_santaToken.mint(msg.sender);
return;
}
revert SantasList__NotNice();
}

This allows a malicious third party to grief any already-approved recipient by rewriting the first-pass status to a mismatching value such as NAUGHTY. After that overwrite, the approved user can no longer satisfy the claim conditions and is denied their present.

Risk

Likelihood:

  • Any address can call checkList() at any time because the function has no access control.

  • The attack succeeds after Santa performs a valid approval flow and requires only a single overwrite transaction before the approved user claims.

Impact:

  • Approved users can be denied their presents even after Santa has successfully completed both checks.

  • The attack breaks the integrity of the eligibility system by allowing arbitrary third parties to revoke effective approval without authorization.

Proof of Concept

Add to storage: address attacker = makeAddr("attacker");

function test_AttackerCanOverwriteFirstCheckAndBlockApprovedUserClaim() public {
// Santa approves user
vm.startPrank(santa);
santasList.checkList(user, SantasList.Status.NICE);
santasList.checkTwice(user, SantasList.Status.NICE);
vm.stopPrank();
assertEq(uint256(santasList.getNaughtyOrNiceOnce(user)), uint256(SantasList.Status.NICE));
assertEq(uint256(santasList.getNaughtyOrNiceTwice(user)), uint256(SantasList.Status.NICE));
vm.warp(santasList.CHRISTMAS_2023_BLOCK_TIME() + 1);
// Attacker rewrites the first check after approval
vm.prank(attacker);
santasList.checkList(user, SantasList.Status.NAUGHTY);
assertEq(uint256(santasList.getNaughtyOrNiceOnce(user)), uint256(SantasList.Status.NAUGHTY));
assertEq(uint256(santasList.getNaughtyOrNiceTwice(user)), uint256(SantasList.Status.NICE));
// Approved user can no longer claim
vm.prank(user);
vm.expectRevert(SantasList.SantasList__NotNice.selector);
santasList.collectPresent();
}

Recommended Mitigation

Restrict checkList() so that only Santa can set or modify the first-pass status.

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

As an optional hardening measure, the contract can also prevent later rewrites once the second check has been completed for a user.

Updates

Lead Judging Commences

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