crytic/slither

Slither claims an upgradeTo function is exposed when it (likely?) is not

Open

#1,136 opened on Mar 19, 2022

View on GitHub
 (9 comments) (0 reactions) (0 assignees)Python (4,769 stars) (886 forks)batch import
enhancementgood first issue

Description

Describe the issue:

When running Slither on this UUPS upgradeable contract](https://github.com/OpenQDev/OpenQ-Contracts/blob/development/contracts/OpenQ/Implementations/OpenQV0.sol), it triggers the unprotected-upgradeable-contract critical warning as shown below:

However, the latest OpenZeppelin UUPSUpgradeable.sol does indeed protect its upgradeTo method with both onlyProxy, as well as an optional _authorizeUpgrade method which I have onlyOwnered as seen here.

So I believe that only an owner calling via the proxy will be able to call upgradeTo....unless I'm wrong and missing something and Slither is doing its wonderful job 😅.

Code example to reproduce the issue:

git clone https://github.com/OpenQDev/OpenQ-Contracts.git cd OpenQ-Contracts solc-select use 0.8.12 slither . --exclude-dependencies

Version:

slither 0.8.2

Relevant log output:

OpenQV0 (contracts/OpenQ/Implementations/OpenQV0.sol#18-254) is an upgradeable contract that does not protect its initiliaze functions: OpenQV0.initialize(address) (contracts/OpenQ/Implementations/OpenQV0.sol#30-35). Anyone can delete the contract with: UUPSUpgradeable.upgradeTo(address) (node_modules/@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol#72-75)UUPSUpgradeable.upgradeToAndCall(address,bytes) (node_modules/@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol#85-88)Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#unprotected-upgradeable-contract

Contributor guide

Tech stack
python
Domain
securitytesting
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Basic understanding of SlitherFamiliarity with Solidity upgradeable contractsKnowledge of OpenZeppelin UUPS pattern
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40
Research direction
Investigate Slither's 'unprotected upgradeable contract' detector logic in the source code (likely in the detectors module). Look at the referenced OpenZeppelin UUPSUpgradeable.sol to confirm that upgradeTo is protected by onlyProxy and the optional authorizeUpgrade. Check the issue comments for any maintainer responses or additional context. Then determine if the false positive is due to Slither not recognizing the onlyProxy modifier or the authorizeUpgrade override.