<\/p>\n
<\/p>\n
Through the Ethereum bug bounty initiative, we acquired a report regarding a defect found within the new experimental ABI encoder (known as ABIEncoderV2). Upon further examination, it became evident that the feature experiences several variations of a similar nature. The opening section of this announcement delves into the specifics of this issue. Though the new ABI encoder remains tagged as experimental, we still believe it warrants a significant announcement as it is currently deployed on the mainnet.<\/p>\n
<\/p>\n
Furthermore, two minor issues in the optimizer have been recognized over the last fortnight, one of which was resolved with Solidity v0.5.6. Both were introduced with version 0.5.5. Refer to the latter section of this announcement for the specifics.<\/p>\n
<\/p>\n
The 0.5.7 release<\/a> encompasses the fixes for all issues detailed in this communication.<\/p>\n <\/p>\n All the defects cited here should be readily observable in tests pertaining to the corresponding code paths, particularly when executed with all combinations of zero and nonzero values.<\/p>\n <\/p>\n Acknowledgments to the Melonport team (Travis Jacobs & Jenna Zenk) and the Melon Council (Nick Munoz-McDonald, Martin Lundfall, Matt di Ferrante & Adam Kolar), who reported this through the Ethereum bug bounty initiative!<\/p>\n <\/p>\n <\/p>\n If you have deployed contracts utilizing the experimental ABI encoder V2, they may potentially be impacted. This implies that only contracts incorporating the following directive within the source code could be susceptible:<\/p>\n <\/p>\n <\/p>\n Moreover, there are several conditions necessary for the bug to activate. Refer to technical details below for additional information.<\/p>\n <\/p>\n To the best of our knowledge, there are approximately 2500 contracts operational on mainnet that utilize the experimental ABIEncoderV2. It remains uncertain how many of these may contain the flaw.<\/p>\n <\/p>\n <\/p>\n The defect manifests only when all of the following stipulations are satisfied:<\/p>\n <\/p>\n <\/p>\n Additionally, under the following scenarios, your code is NOT impacted:<\/p>\n <\/p>\n <\/p>\n Should you have a contract that fulfills these criteria, and wish to confirm its vulnerability, please contact us via security@ethereum.org<\/a>.<\/p>\n <\/p>\n <\/p>\n To adopt a cautious approach regarding modifications, the experimental ABI encoder has been accessible only when explicitly activated, enabling users to engage with it and assess its functionality without excessive reliance prior to it being deemed stable.<\/p>\n <\/p>\n We strive for excellence and have recently commenced ‘semantic’ fuzzing on certain sections of OSS-Fuzz<\/a> (previously, we applied crash-fuzzing on the compiler, though this did not validate compiler accuracy).<\/p>\n <\/p>\n For developers\u2014detecting bugs within the Solidity compiler is challenging with tools such as vulnerability detectors, as instruments that function on source code or AST representations do not catch defects arising solely in the compiled bytecode.<\/p>\n <\/p>\n The most effective method to safeguard against such flaws is to implement a rigorous set of end-to-end tests for your contracts (ensuring all code pathways are verified), as bugs in a compiler are likely to be apparent and result in erroneous data.<\/p>\n <\/p>\n <\/p>\n Naturally, any defect can yield significantly different consequences based on the program’s control flow; however, we anticipate that this is more inclined to cause malfunction rather than be exploitable.<\/p>\n <\/p>\n When triggered, the bug under certain conditions will send corrupted parameters during method invocations to other contracts.<\/p>\n <\/p>\n <\/p>\n 2019-03-16:<\/p>\n <\/p>\n <\/p>\n 2019-03-16 to 2019-03-21:<\/p>\n <\/p>\n <\/p>\n 2019-03-20:<\/p>\n <\/p>\n <\/p>\n 2019-03-26:<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n The Contract ABI is a guideline on how data can be exchanged with contracts from the external environment (a Dapp) or during interactions among contracts. It accommodates various types of data, encompassing simple values like numbers, bytes, and strings, as well as more intricate data types, including arrays and structs.<\/p>\n <\/p>\n Upon receiving input data, a contract must decode this information (this is accomplished by the “ABI decoder”) and before returning data or transmitting data to another contract, it must encode it (this is conducted by the “ABI encoder”). The Solidity compiler produces these two segments of code for every defined function within a contract (and for abi.encode<\/span> and abi.decode<\/span>). In the Solidity compiler, the subsystem responsible for generating the encoder and decoder is referred to as the “ABI encoder”.<\/p>\n <\/p>\n In mid-2017, the Solidity team commenced work on a new implementation called “ABI encoder V2” aimed at producing more versatile, secure, efficient, and auditable code generation. This experimental code generator has been available to users since late 2017 with the launch of version 0.4.19, when explicitly enabled.<\/p>\n <\/p>\n <\/p>\n The experimental ABI encoder does not appropriately manage non-integer values that are shorter than 32 bytes. This concern pertains to bytesNN<\/span> types, bool<\/span>, enum<\/span>, and other types when they are included in an array or a struct and encoded directly from storage. This indicates that these storage references must be utilized directly within abi.encode(…)<\/span>, as parameters in external function calls or in event data without first assigning to a local variable. Employing return<\/span> does not trigger the flaw. The types bytesNN<\/span> and bool<\/span> will lead to corrupted output, while enum<\/span> could result in an invalid revert<\/span>.<\/p>\n <\/p>\n Moreover, arrays with elements shorter than 32 bytes may not be managed correctly even if the base type is an integer. Encoding such arrays in the manner outlined above can result in other data within the encoding being overwritten if the count of elements encoded is not a multiple of the number of elements that can fit in a single slot. If nothing follows the array in the encoding (noting that dynamically-sized arrays are always encoded after statically-sized arrays with statically-sized content), or if merely a single array is encoded, no additional data is overwritten.<\/p>\n Unrelated to the ABI encoder issue discussed previously, two defects have been discovered in the optimizer. Both were introduced with the release of version 0.5.5 (on 5th March). They are unlikely to appear in code produced by the compiler, unless inline assembly is utilized.<\/p>\n <\/p>\n These two defects were recognized through the recent inclusion of Solidity in OSS-Fuzz<\/a> – a security toolkit aimed at identifying discrepancies or problems across various projects. For Solidity, we have incorporated several different fuzzers that assess distinct aspects of the compiler.<\/p>\n <\/p>\nWho Needs to Be Aware<\/h2>\n
pragma experimental ABIEncoderV2<\/span>;<\/span>\n<\/span><\/code><\/pre>\n<\/div>\nHow to Determine if a Contract is Vulnerable<\/h2>\n
\n
\n
Preventing Similar Flaws in the Future<\/h2>\n
Potential Consequences<\/h2>\n
Timeline<\/h2>\n
\n
\n
\n
\n
Technical details<\/h2>\n
Background<\/h3>\n
The flaw<\/h3>\n
\n<\/p>\n