Lens Protocol V2 - mrudenko's results

An open technology stack, builders can create social front-ends or integrate Lens social capabilities.

General Information

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

Lens Protocol

Findings Distribution

Researcher Performance

Rank: 23/26

Findings: 1

Award: $31.38

QA:
grade-b

🌟 Selected for report: 0

🚀 Solo Findings: 0

Awards

31.3772 USDC - $31.38

Labels

bug
downgraded by judge
grade-b
QA (Quality Assurance)
sponsor disputed
Q-15

External Links

Lines of code

https://github.com/code-423n4/2023-07-lens/blob/cdef6ebc6266c44c7068bc1c4c04e12bf0d67ead/contracts/namespaces/LensHandles.sol#L187

Vulnerability details

Impact

Severity: Medium Likelihood: Medium

Proof of Concept

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(); } }

Tools Used

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.

Assessed type

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)

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter