Smart Contract Audit Report for 1inch

Management Summary

1inch contacted Sayfer to perform a security audit on their smart contract.

This report documents the research carried out by Sayfer targeting the selected resources defined under the research scope. Particularly, this report displays the security posture review for 1inch’s smart contract. We applied a combination of manual inspection and automated scanning tools

Over the research period of 15 audit days, we discovered 3 vulnerabilities and 1 informational note in the audited contract.
None of these findings are considered critical, the contract can be deployed as is. All the findings were addresses and fixed by the 1inch’s team.

Risk Methodology

At Sayfer, we are committed to delivering the highest quality smart contract audits to our clients. That’s why we have implemented a comprehensive risk assessment model to evaluate the severity of our findings and provide our clients with the best possible recommendations for mitigation.

Our risk assessment model is based on two key factors: IMPACT and LIKELIHOOD. Impact refers to the potential harm that could result from an issue, such as financial loss, reputational damage, or a non-operational system. Likelihood refers to the probability that an issue will occur, taking into account factors such as the complexity of the contract and the number of potential attackers.

By combining these two factors, we can create a comprehensive understanding of the risk posed by a particular issue and provide our clients with a clear and actionable assessment of the severity of the issue. This approach allows us to prioritize our recommendations and ensure that our clients receive the best possible advice on how to protect their smart contracts.

Risk is defined as follows:

Protocol Overview

1inch enhancing the efficiency of operations within the Layer 2 blockchain environment. Given that operations with larger calldata tend to be more costly in Layer 2, the central focus is to reduce the size of the calldata. To accomplish this, a strategy of calldata compression is employed, this strategy primarily involves off-chain operations and uses a mechanism referred to as the DecompressorExtension, which allows for the recovery of the compressed calldata.

Several key techniques are utilized for the compression of the calldata:

1. Compression of consecutive zero bytes: This technique reduces the overall size of the calldata by consolidating sequential zero bytes into a more compact format.
2. Copying consecutive bytes: In certain instances, replication of sequential bytes is employed as a data compression strategy.
3. Dictionary-based replacement: Two distinct methods are used to replace a segment of the calldata with an index drawn from a predefined dictionary, leading to more efficient data representation.

Audit Findings

Centralization Risk

Description

If the _setData function is exposed to the contract owner, which seems to be the intended way to use the contract according to the README, this introduces a centralization risk for every project that is using the DecompressorExtension.

function _setData(uint256 offset, bytes32 data) internal
validDictAccess(offset) {
    unchecked {
        _dict[offset] = data;
    }
}

An owner could front-run a call from a user and change the corresponding dict key before the call is executed, which allows him to change the calldata arbitrarily. Therefore, it becomes impossible for a user to verify the (decompressed) calldata before a call.

The mutability of the dict entries also means that other smart contracts which call decompress cannot store the compressed calldata immutable, as its interpretation may change.

Mitigation

One solution for this would be to disallow changing existing dictionary entries, but a better understanding of the business needs and options is needed.

No Ownable Implementation

Description

The README states multiple times about implementing Ownable form OpenZeppelin. In reality, the contract does not implement or extend Owneable which could be confusing and misleading to project owners.

From the README:

This contract provides a `DecompressorExtension` abstract
contract that extends `Ownable` from the OpenZeppelin
library.

This is dangerous as the project owners might assume there is an access control mechanism in place, which doesn’t exist.

Mitigation

Implement ownership functionality by inheriting from Ownable or update the README to state that the user is the one who should be taking care of the access control

Gas DoS Attack

Description

It is very easy to submit (short) input to decompress that results in huge decompressed calldata, i.e. the equivalent of a zip bomb.

For instance, many 00111111 bytes followed by some other data can be submitted using case 0, resulting in huge memory expansion costs:

case 0 {
    let size := add(byte(0, data), 1)
    calldatacopy(outptr, calldatasize(), size)
    inptr := add(inptr, 1)
    outptr := add(outptr, size)
    continue
}

If the user submits this transaction himself, this is not a problem, as he just wastes his own funds, hence the low risk given to this finding.

However, there are some scenarios where this could enable an attack. For instance, we might have a relayer contract that calls a smart contract where the developers took care that the gas usage of every function is bounded. If this smart contract now starts using the extension, the gas usage becomes unbounded, as the data variable is a user controlled input.

Mitigation

Avoiding this vulnerability will be hard, there is a need for a better understanding of the business needs.

One solution is to introduce an optional length limit for the decompressed calldata, although this might be hard/impossible to set depending on the functions.
Other than this technical solution, we think this should be at least documented on the README or in an inline comment.

Incompatibility with ERC-2771/meta transactions

Description

The extension is incompatible with the ERC-2771 standard where the relayer appends the original sender to the calldata (as this would lead to compression errors).

This should not be a huge problem as the contracts still support normal (uncompressed) calls, but it means that compression cannot be used in conjunction with meta transactions.

Our assumption is that at some point this contract will be a basic building block for other protocols, which these protocols may use ERC-2771, which would then no longer work when using compressed calldata.

Mitigation

If this is relevant, implement ERC-2771