Announcement of Solidity Storage Array Bug
This article discusses two distinct bugs related to storage arrays which are otherwise not linked. Both have lingered in the compiler for an extended period and were only uncovered recently, despite a contract that encompasses them likely demonstrating issues during tests.
Daenam Kim, assisted by Nguyen Pham, both associated with Curvegrid, identified a problem where erroneous data is recorded in relation to arrays of signed integers.
This issue has existed since Solidity version 0.4.7 and is regarded as the more critical of the two. If these arrays incorporate negative integers in particular scenarios, it will result in data corruption, thereby making the bug relatively easy to identify.
Through the Ethereum bug bounty initiative, we received a notification regarding a vulnerability in the new experimental ABI encoder (denoted as ABIEncoderV2). The new ABI encoder is still categorized as experimental, but we believe this warrants a significant announcement as it is already utilized on mainnet.
Acknowledgments go to Ming Chuan Lin (from https://www.secondstate.io) for both uncovering and rectifying the bug!
The 0.5.10 release includes the resolutions for the bugs.
Currently, we do not intend to release a fix for the legacy 0.4.x series of Solidity, although we may consider it if there is considerable demand.
Both bugs should be easily discernible in tests that involve the relevant code paths.
Further details regarding the two bugs can be found below.
Signed Integer Array Bug
Who needs to be cautious
Should you have deployed contracts utilizing signed integer arrays in storage and either directly assign
- a literal array containing at least one negative element (x = [-1, -2, -3];) or
- an existing array of a different signed integer type
to it, this will result in data corruption within the storage array.
Contracts that solely assign individual array components (for example, x[2] = -1;) remain unaffected.
How to ascertain if the contract is susceptible
If you are utilizing signed integer arrays in storage, attempt to execute tests incorporating negative values. The expected outcome should be that the actual value recorded is positive instead of negative.
If you possess a contract that meets these criteria and wish to confirm whether it is truly susceptible, you can contact us via security@ethereum.org.
Technical specifics
Storage arrays can accept assignments from arrays of varying types. During this transfer and assignment operation, a type conversion occurs for each of the elements. In addition to the conversion, particularly if the signed integer type is less than 256 bits, certain bits of the value need to be cleared in preparation to store multiple values within the same storage slot.
The bits to clear were incorrectly decided from the source rather than the target type. This results in an excessive number of bits being cleared. Specifically, the sign bit will be cleared, causing the value to appear positive.
ABIEncoderV2 Array Bug
Who should exercise caution
If you have deployed contracts employing the experimental ABI encoder V2, those may be at risk. This indicates that only contracts utilizing the subsequent directive within the source code can be influenced:
pragma experimental ABIEncoderV2;
Moreover, various conditions must be fulfilled for the bug to be activated. Refer to the technical specifics further down for additional information.
How to check if the contract is vulnerable
The bug only presents itself if all of the following conditions are satisfied:
- Storage data involving arrays or structs is sent directly to an external function call, to abi.encode or to event data without previously assigning it to a local (memory) variable AND
- this data either includes an array of structs or an array of statically-sized arrays (i.e. at least two-dimensional).
Additionally, in the following scenario, your code is NOT impacted:
- if you solely return such data and refrain from using it in abi.encode, external calls, or event data.
Potential ramifications
Naturally, any bug can have significantly different consequences based on the program’s control flow, but we foresee that this is more prone to cause operational dysfunction than exploitation.
Upon triggering, the bug will, under specific circumstances, send corrupted parameters on method calls to other contracts.
Technical specifics
During the encoding phase, the experimental ABI encoder fails to advance correctly to the subsequent element in an array when the elements occupy more than a single storage slot.
This issue is exclusive to elements that are structs or statically-sized arrays. Arrays of dynamically-sized arrays or of fundamental data types are unaffected.
The specific impact you will observe is that data appears “shifted” in the encoded array: If you have an array of type uint[2][] and it comprises the data
[[1, 2], [3, 4], [5, 6]], then it will be encoded as [[1, 2], [2, 3], [3, 4]] as the encoder only progresses by one slot between elements instead of two.
This article was collaboratively written by @axic, @chriseth, @holiman
