Platform: Code4rena
Start Date: 17/07/2023
Pot Size: $85,500 USDC
Total HM: 11
Participants: 26
Period: 14 days
Judge: Picodes
Total Solo HM: 1
Id: 263
League: ETH
Rank: 23/26
Findings: 1
Award: $31.38
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: MiloTruck
Also found by: 0xAnah, AlexCzm, Bughunter101, BugzyVonBuggernaut, DavidGiladi, Emmanuel, Iurii3, Kaysoft, MohammedRizwan, Prestige, Rolezn, Sathish9098, Stormreckson, adeolu, descharre, evmboi32, fatherOfBlocks, ginlee, ihtishamsudo, juancito, mrudenko, tnquanghuy0512
31.3772 USDC - $31.38
Severity: Medium Likelihood: Medium
The DANGER__disableTokenGuardian function in the LensHandles.sol contract uses the onlyEOA modifier to restrict access to external owned accounts (EOAs). However, this restriction can be bypassed by calling the function from the constructor of another contract. This could allow an attacker to disable the token guardian, potentially leading to unauthorized actions.
Additionally, the getTokenGuardianDisablingTimestamp function does not use the onlyEOA modifier, which means that _tokenGuardianDisablingTimestamp[wallet] can be created from a contract. This could lead to unexpected behavior or potential manipulation of the disabling timestamp.
An attacker could create a new contract that calls the DANGER__disableTokenGuardian function in its constructor. Since the constructor is called during contract creation, it is considered an EOA during that transaction, allowing it to bypass the onlyEOA modifier.
contract Attacker { constructor(LensHandles target) { target.DANGER__disableTokenGuardian(); } }
Manual Code Review
Apply the onlyEOA modifier or similar access controls to the getTokenGuardianDisablingTimestamp function to prevent it from being called from a contract. This could help prevent potential misuse or manipulation of the disabling timestamp.
Access Control
#0 - 141345
2023-08-04T10:01:58Z
Lack detailed POC about impact/loss.
QA might be more appropriate.
#1 - vicnaum
2023-08-07T16:17:36Z
OnlyEOA modifier is used here for the safety of the contracts (so tokens don't get locked in the contracts that don't support Guardian). Contracts have TokenGuardian disabled by default, so disabling in the constructor doesn't make much sense - it's disabled anyway for the contracts. Moreover, if the contract is specifically constructed to perform such manipulations - it is assumed to be aware of TokenGuardian functionality and is assumed to know what it's doing (cause TokenGuardian only affects/harms the address that enabled/disabled it). I would say QA is a maximum severity here, or even dispute validity.
#2 - c4-sponsor
2023-08-07T16:57:24Z
vicnaum marked the issue as sponsor disputed
#3 - c4-judge
2023-08-27T17:33:58Z
Picodes changed the severity to QA (Quality Assurance)