This compiler range, for example, allows testing with Solidity compiler version 0.6.x but deployment with 0.7.x. While any breaking syntactic changes will be caught at compile time, there is a risk that the silent change in 0.7.0 which applies to exponentiation/shift operand types might affect the FairSide formula or other mathematical calculations, thus breaking assumptions and accounting.
The opposite scenario may also happen where testing is performed with Solidity compiler version 0.7.x but deployment with 0.6.x, which may allow bugs fixed in 0.7.x to be present in the deployed code.
Use the same compiler version both for testing and deployment by enforcing this in the pragma itself. An unlocked/floating pragma is risky especially one that ranges across a breaking compiler minor version.
fairside-core
commented
3 years ago
Handle
0xRajeev
Vulnerability details
Impact
All contracts use a Solidity compiler pragma range >=0.6.0 <0.8.0 which spans a breaking change version 0.7.0. This compiler range is very broad and includes many syntactic/semantic changes across the versions. Specifically, see silent changes in https://docs.soliditylang.org/en/v0.7.0/070-breaking-changes.html#silent-changes-of-the-semantics.
This compiler range, for example, allows testing with Solidity compiler version 0.6.x but deployment with 0.7.x. While any breaking syntactic changes will be caught at compile time, there is a risk that the silent change in 0.7.0 which applies to exponentiation/shift operand types might affect the FairSide formula or other mathematical calculations, thus breaking assumptions and accounting.
The opposite scenario may also happen where testing is performed with Solidity compiler version 0.7.x but deployment with 0.6.x, which may allow bugs fixed in 0.7.x to be present in the deployed code.
Proof of Concept
https://github.com/code-423n4/2021-05-FairSide/blob/3e9f6d40f70feb67743bdc70d7db9f5e3a1c3c96/contracts/token/FSD.sol#L3
https://github.com/code-423n4/2021-05-FairSide/blob/3e9f6d40f70feb67743bdc70d7db9f5e3a1c3c96/contracts/conviction/FairSideConviction.sol#L9
https://docs.soliditylang.org/en/v0.7.0/070-breaking-changes.html#silent-changes-of-the-semantics
https://docs.soliditylang.org/en/v0.7.0/070-breaking-changes.html#
https://docs.soliditylang.org/en/v0.8.4/bugs.html
Tools Used
Manual Analysis
Recommended Mitigation Steps
Use the same compiler version both for testing and deployment by enforcing this in the pragma itself. An unlocked/floating pragma is risky especially one that ranges across a breaking compiler minor version.