Wednesday, June 25, 2025
HomeEthereumSolidity Optimizer and ABIEncoderV2 Bug

Solidity Optimizer and ABIEncoderV2 Bug


Solidity Optimizer and ABIEncoderV2 Bug Announcement

By means of the Ethereum bug bounty program, we obtained a report a few flaw throughout the new experimental ABI encoder (known as ABIEncoderV2). Upon investigation, it was discovered that the element suffers from just a few completely different variations of the identical sort. The primary a part of this announcement explains this bug intimately. The brand new ABI encoder continues to be marked as experimental, however we nonetheless assume that this deserves a outstanding announcement since it’s already used on mainnet.

Moreover, two low-impact bugs within the optimizer have been recognized over the previous two weeks, one among which was mounted with Solidity v0.5.6. Each had been launched with model 0.5.5. See the second a part of this announcement for particulars.

The 0.5.7 launch incorporates the fixes to all bugs defined on this weblog submit.

All of the bugs talked about right here ought to be simply seen in exams that contact the related code paths, not less than when run with all mixtures of zero and nonzero values.

Credit to Melonport group (Travis Jacobs & Jenna Zenk) and the Melon Council (Nick Munoz-McDonald, Martin Lundfall, Matt di Ferrante & Adam Kolar), who reported this by way of the Ethereum bug bounty program!

Who ought to be involved

If in case you have deployed contracts which use the experimental ABI encoder V2, then these may be affected. Because of this solely contracts which use the next directive throughout the supply code could be affected:

pragma experimental ABIEncoderV2;

Moreover, there are a selection of necessities for the bug to set off. See technical particulars additional under for extra info.

So far as we are able to inform, there are about 2500 contracts reside on mainnet that use the experimental ABIEncoderV2. It isn’t clear what number of of them include the bug.

Easy methods to verify if contract is weak

The bug solely manifests itself when all the following circumstances are met:

  • Storage information involving arrays or structs is shipped on to an exterior operate name, to abi.encode or to occasion information with out prior task to an area (reminiscence) variable AND
  • there’s an array that incorporates components with dimension lower than 32 bytes or a struct that has components that share a storage slot or members of sort bytesNN shorter than 32 bytes.

Along with that, within the following conditions, your code is NOT affected:

  • if all of your structs or arrays solely use uint256 or int256 varieties
  • should you solely use integer varieties (that could be shorter) and solely encode at most one array at a time
  • should you solely return such information and don’t use it in abi.encode, exterior calls or occasion information.

If in case you have a contract that meets these circumstances, and need to confirm whether or not the contract is certainly weak, you’ll be able to attain out to us by way of safety@ethereum.org.

Easy methods to forestall a lot of these flaws sooner or later

As a way to be conservative about modifications, the experimental ABI encoder has been obtainable solely when explicitly enabled, to permit folks to work together with it and take a look at it with out placing an excessive amount of belief in it earlier than it’s thought-about steady.

We do our greatest to make sure prime quality, and have just lately began engaged on ‘semantic’ fuzzing of sure elements on OSS-Fuzz (we now have beforehand crash-fuzzed the compiler, however that didn’t take a look at compiler correctness).

For builders — bugs throughout the Solidity compiler are tough to detect with instruments like vulnerability detectors, since instruments which function on supply code or AST-representations don’t detect flaws which are launched solely into the compiled bytecode.

One of the best ways to guard towards a lot of these flaws is to have a rigorous set of end-to-end exams to your contracts (verifying all code paths), since bugs in a compiler very possible will not be “silent” and as an alternative manifest in invalid information.

Doable penalties

Naturally, any bug can have wildly various penalties relying on this system management movement, however we count on that that is extra prone to result in malfunction than exploitability.

The bug, when triggered, will underneath sure circumstances ship corrupt parameters on methodology invocations to different contracts.

Timeline

2019-03-16:

  • Report by way of bug bounty, about corruption induced when studying from arrays of booleans immediately from storage into ABI encoder.

2019-03-16 to 2019-03-21:

  • Investigation of root trigger, evaluation of affected contracts. An unexpectedly excessive rely of contracts compiled with the experimental encoder had been discovered deployed on mainnet, many with out verified source-code.
  • Investigation of bug discovered extra methods to set off the bug, e.g. utilizing structs. Moreover, an array overflow bug was present in the identical routine.
  • A handful of contracts discovered on Github had been checked, and none had been discovered to be affected.
  • A bugfix to the ABI encoder was made.

2019-03-20:

  • Resolution to make info public.
  • Reasoning: It might not be possible to detect all weak contracts and attain out to all authors in a well timed method, and it might be good to stop additional proliferation of weak contracts on mainnet.

2019-03-26:

  • New compiler launch, model 0.5.7.
  • This submit launched.

Technical particulars

Background

The Contract ABI is a specification how information could be exchanged with contracts from the skin (a Dapp) or when interacting between contracts. It helps a wide range of forms of information, together with easy values like numbers, bytes and strings, in addition to extra advanced information varieties, together with arrays and structs.

When a contract receives enter information, it should decode that (that is accomplished by the “ABI decoder”) and previous to returning information or sending information to a different contract, it should encode it (that is accomplished by the “ABI encoder”). The Solidity compiler generates these two items of code for every outlined operate in a contract (and in addition for abi.encode and abi.decode). Within the Solidity compiler the subsystem producing the encoder and decoder is known as the “ABI encoder”.

In mid-2017 the Solidity group began to work on a contemporary implementation named “ABI encoder V2” with the aim of getting a extra versatile, secure, performant and auditable code generator. This experimental code generator, when explicitly enabled, has been supplied to customers for the reason that finish of 2017 with the 0.4.19 launch.

The flaw

The experimental ABI encoder doesn’t deal with non-integer values shorter than 32 bytes correctly. This is applicable to bytesNN varieties, bool, enum and different varieties when they’re a part of an array or a struct and encoded immediately from storage. This implies these storage references have for use immediately inside abi.encode(…), as arguments in exterior operate calls or in occasion information with out prior task to an area variable. Utilizing return doesn’t set off the bug. The kinds bytesNN and bool will end in corrupted information whereas enum would possibly result in an invalid revert.

Moreover, arrays with components shorter than 32 bytes is probably not dealt with appropriately even when the bottom sort is an integer sort. Encoding such arrays in the best way described above can result in different information within the encoding being overwritten if the variety of components encoded shouldn’t be a a number of of the variety of components that match a single slot. If nothing follows the array within the encoding (notice that dynamically-sized arrays are at all times encoded after statically-sized arrays with statically-sized content material), or if solely a single array is encoded, no different information is overwritten.


Unrelated to the ABI encoder challenge defined above, two bugs have been discovered within the optimiser. Each have been launched with 0.5.5 (launched on fifth of March). They’re unlikely to happen in code generated by the compiler, except inline meeting is used.

These two bugs have been recognized by way of the latest addition of Solidity to OSS-Fuzz – a safety toolkit for locating discrepancies or points in a wide range of initiatives. For Solidity we now have included a number of completely different fuzzers testing completely different facets of the compiler.

  1. The optimizer turns opcode sequences like ((x << a) << b)), the place a and b are compile-time constants, into (x << (a + b)) whereas not dealing with overflow within the addition correctly.
  2. The optimizer incorrectly handles the byte opcode if the fixed 31 is used as second argument. This may occur when performing index entry on bytesNN varieties with a compile-time fixed worth (not index) of 31 or when utilizing the byte opcode in inline meeting.

This submit was collectively composed by @axic, @chriseth, @holiman

RELATED ARTICLES

Most Popular

Recent Comments