Limit inflation in ABI decoded output

[ricmoo]

Describe the Feature

TL;DR: When decoding ABI-encoded data, it is possible to use a malicious ABI fragment and specially constructed data to cause excessive memory and processing power when decoding dynamic arrays, resulting in a denial-of-service vector.

More Background

When dynamic-length items are ABI-encoded, a fixed-length item is inserted, which is a pointer to a position in the data after all fixed-length items, which encodes the dynamic value.

This form of data may be intentional, as it can be used as a form of compression for data passed to a contract. It works by using the same pointer for multiple fields. For example, imagine the following example:

// The Interface
iface = new Interface([ "function foo(string a, string b) returns (uint)" ]);

// The standard encoding: (we will ignore the selector `0x124a83fa` in the output)
iface.encodeFunctionData("foo", [ "hello world", "hello world" ]);

0x00: 0000000000000000000000000000000000000000000000000000000000000040 // Pointer to 0x40
0x20: 0000000000000000000000000000000000000000000000000000000000000080 // Pointer to 0x80
0x40: 000000000000000000000000000000000000000000000000000000000000000b // First string length (11)
0x60: 68656c6c6f20776f726c64000000000000000000000000000000000000000000 // First string data
0x80: 000000000000000000000000000000000000000000000000000000000000000b // Second string length (11)
0xa0: 68656c6c6f20776f726c64000000000000000000000000000000000000000000 // Second string data

// However, another (valid) encoding could exploit the fact that both strings are identical
0x00: 0000000000000000000000000000000000000000000000000000000000000040 // Pointer to 0x40
0x20: 0000000000000000000000000000000000000000000000000000000000000040 // Share the pointer***
0x40: 000000000000000000000000000000000000000000000000000000000000000b // String length (11)
0x60: 68656c6c6f20776f726c64000000000000000000000000000000000000000000 // String data

*** Notice the second element in the ABI-encoding (offset 0x20) can just
    share the same reference as the first element, which saves 64 bytes.

However, careful construction of ABI-encoded data allows this technique to re-use pointers excessively, which will exhaust system memory and processing power, causing a DoS attack vector.

So, this feature is to introduce a sane default inflation ratio and a means to adjust that ratio if needed.

An article will be released soon which outlines the issue more, which this issue will link to.

Code Example

No response

[ricmoo]

I'm still experimenting with some details, but the current proposed fix will use a default ratio of 1024, which means up to 1024 times the amount of decoded data can be read from the encoded data.

However to adjust this, the following will be possible:

// Disable any pointer reuse; only allow each byte to be effectively be read once
ethers.AbiCoder._setDefaultMaxInflation(1);

// Disable limit checking; allows decoding arbitrary-sized output, but may exhaust memory and the CPU.
ethers.AbiCoder._setDefaultMaxInflation(0);

// Allow custom levels of compression; allow for 1 million times inflation
ethers.AbiCoder._setDefaultMaxInflation(1000000);

I don't imagine anyone needing to adjust any of this though, and it should "just work". :)

[ricmoo]

This has been published in v6.10.0.