Inheritable Smart Contract Wallet
First Flight #35
Beginner FriendlySolidity
100 EXP
View results
Previous Next
Submission Details
Severity: medium
Valid

Only some of the owner's interactions reset timer

dappscout

Summary

Not all owner interactions with the InheritanceManager contract reset the 90-day inactivity timer, creating a security vulnerability where the inheritance process could be triggered prematurely despite recent owner activity.

Vulnerability Details

The InheritanceManager contract is designed to allow beneficiaries to inherit assets after 90 days of owner inactivity. However, the implementation fails to reset the deadline timer in several key owner-only functions:

  1. removeBeneficiary(address) - Missing _setDeadline() call

  2. createEstateNFT(string, uint256, address) - Missing _setDeadline() call

  3. contractInteractions(address, bytes, uint256, bool) - Missing _setDeadline() call

The contract also contains several view functions that don't modify state (so they shouldn't reset the timer):

  • _getBeneficiaryIndex(address)

  • getDeadline()

  • getOwner()

  • getIsInherited()

  • getTrustee()

  • getNftValue(uint256)

  • getAssetToPay()

This inconsistency means that if an owner only interacts with the contract through the functions missing the timer reset, the deadline could expire despite active usage, allowing beneficiaries to prematurely inherit the assets

Impact

  1. Premature Inheritance and Fund Loss: Beneficiaries could inherit assets while the owner is still actively using the contract, resulting in unauthorized access to funds. This can lead to complete loss of all ETH and ERC20 tokens stored in the contract, as beneficiaries can call withdrawInheritedFunds() to distribute these assets among

  2. Loss of Owner Control: The owner could lose control of their assets unexpectedly, even while actively managing them through specific functions.

  3. Broken Trust Assumptions: The contract's core functionality as a dead man's switch is compromised, as it may trigger while the owner is still active.

  4. Inconsistent Security Model: Users expect all meaningful interactions with the contract to reset the timer, but the current implementation creates a confusing security model where some actions maintain security while others silently allow it to degrade.

PoC:

function test_removeBeneficiaryDoesNotResetDeadline() public {
address user2 = makeAddr("user2");
// Initial setup - add beneficiaries
vm.startPrank(owner);
im.addBeneficiery(user1);
im.addBeneficiery(user2);
vm.stopPrank();
// Record the deadline after adding beneficiaries
uint256 initialDeadline = im.getDeadline();
// Warp time forward slightly (but not past the deadline)
vm.warp(10 days);
// Owner removes a beneficiary - this should reset the deadline but doesn't
vm.startPrank(owner);
im.removeBeneficiary(user2);
vm.stopPrank();
// Check that the deadline hasn't changed
uint256 newDeadline = im.getDeadline();
assertEq(newDeadline, initialDeadline, "Deadline should not have changed after removeBeneficiary");
// Warp time to just after the initial deadline
vm.warp(initialDeadline + 1);
vm.deal(address(im), 10e18);
// User1 can now inherit, even though the owner was active 10 days ago
vm.startPrank(user1);
im.inherit();
vm.stopPrank();
// Verify inheritance was successful
assertTrue(im.getIsInherited(), "Inheritance should have been triggered");
// In a secure implementation, the deadline would have been extended when the owner
// called removeBeneficiary, preventing this premature inheritance
}

Tools Used

Manual code review, Foundry

Recommendations

Add _setDeadline() to all owner-only functions that modify state to ensure the timer is consistently reset with any owner activity

Updates

Lead Judging Commences

0xtimefliez Lead Judge 9 months ago
Submission Judgement Published
Validated
Assigned finding tags:

functions do not reset the deadline

Support

FAQs

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

Give us feedback!