A flaw in the Solidity optimizer was disclosed through the Ethereum Foundation Bounty initiative, by Christoph Jentzsch. This flaw was corrected as of 2017-05-03, with the release of Solidity 0.4.11.
Background
The flaw in question was related to the manner in which the optimizer enhances constants within the bytecode. By “bytecode constants,” we refer to any items that are PUSHed onto the stack (not to be confused with Solidity constants). For instance, if the value 0xfffffffffffffffffffffffffffffffffffffffffffffffe is PUSHed, the optimizer has the option to perform PUSH32 0xfffffffffffffffffffffffffffffffffffffffffffffffe, or it may opt to encode this as PUSH1 1; NOT;.
A malfunction in the optimizer caused the optimizations of bytecode constants to fail under specific scenarios, resulting in a procedure that did not accurately reproduce the original constant.
The behavior outlined in the reported flaw was identified in a contract where one method stopped functioning when an unrelated method was incorporated into the contract. After examination, it was found that several conditions needed to occur simultaneously for the flaw to be activated. Any combination of conditions that would cause the flaw would invariably possess the following two criteria:
- The constant must begin with 0xFF… and conclude with a lengthy string of zeroes (or the opposite).
- The identical constant must be used in multiple places, for the optimizer to decide to optimize this specific constant. Alternatively, it needs to be utilized in the constructor, which optimizes for size instead of gas.
Aside from the two conditions mentioned earlier, there are additional, more complex requirements that are necessary.
Analysis
This flaw exists in all released versions of Solidity from at least the summer of 2015 up to the present time. Although the flaw has been around since 2015, it appears quite challenging to trigger via “random” code:
We conducted a static analysis of all contract code implemented on the blockchain and found no occurrences of such an incorrectly generated routine. Please note that the absence of a bug in all the contract code we reviewed does not ensure the lack of such occurrences.
Improvements
To enhance transparency and raise awareness concerning bugs in Solidity, we have initiated the export of information regarding Solidity-related vulnerabilities as JSON files within the Solidity code repository(1,2). We anticipate that block explorers will incorporate this data alongside other contract-related details.
Etherscan has already put this into action, observable here and here.
Regarding the flaw itself, we incorporated a mini-EVM within the optimizer that validates the accuracy of each generated routine at compile time.
Moreover, work has already commenced on a fully-defined and more advanced intermediate language. Future optimizer routines based on this language will be significantly simpler to grasp and audit, ultimately replacing the existing optimizer.
