search

code-423n4 / 2021-09-sushitrident-findings

0 stars 0 forks source link

Unlocked Solidity compiler pragma is risky #49

Open code423n4 opened 3 years ago

code423n4 commented 3 years ago

Handle

0xRajeev

Vulnerability details

Impact

Contracts should be deployed using the same compiler version/flags with which they have been tested.

Using an unlocked pragma of >=0.8.0 which allows different latest versions of Solidity, (including potentially future breaking versions >=0.9.0) is risky because it allows contracts to be accidentally deployed using untested older/newer compiler versions with unfixed/undiscovered bugs.

Proof of Concept

https://github.com/sushiswap/trident/blob/6bd4c053b6213ffc612987eb565aa3813d5f0d13/contracts/pool/IndexPool.sol#L3

https://github.com/sushiswap/trident/blob/6bd4c053b6213ffc612987eb565aa3813d5f0d13/contracts/pool/ConstantProductPool.sol#L3

https://twitter.com/solidity_lang/status/1442550177202679809

https://twitter.com/solidity_lang/status/1442902224263282688

Tools Used

Manual Analysis

Recommended Mitigation Steps

Locking the pragma to a specific version (by not specifying a range, which is possible here because these contracts are not libraries meant to be used with different contracts across compiler versions) ensures that contracts get deployed with the same version as with that tested. Use one of the recent versions, e.g. 0.8.4 or 0.8.5, which has fixed compiler bugs from previous releases and has been around for a few months/releases to give time for any undiscovered/untested bugs to surface. For example, the latest version 0.8.8 was released and a bug was reported 1 day after release.

maxsam4 commented 3 years ago

Solidity version controlled via hardhat config.

alcueca commented 3 years ago

Hardhat config is independent from contract code. Development and deployment could happen from different repositories (using submodule or npm), and therefore testing and deployment bytecode might differ.