informal-evmos-report-2021q4

Security Audit Report

Evmos: Scalable and interoperable Ethereum built on Proof-of-Stake

November-December 2021 Last revised 2022/11/16

Contents Audit overview 4 The Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Scope of this report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Conducted work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Audit Dashboard 6

Engagement Goals 7

Coverage 8

Recommendations 9 Short term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Long term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Findings 10

IF-EVMOS-01: When a contract is deployed, the log contains plenty of error messages 11 Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Steps to reproduce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

IF-EVMOS-02: Compile built-in contracts in the build process 13 Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

IF-EVMOS-03: convert-erc20 gas estimation is inaccurate 14

IF-EVMOS-04: A destructed contract resurrects in the next block 15 Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

IF-EVMOS-05: No receipt for a contract that stores lots of data 17 Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

IF-EVMOS-06: IERC20 Contracts may execute arbitrary code 19 Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

IF-EVMOS-07: Delegation and unbonding transfers rewards 26 Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

IF-EVMOS-08: Delegating over 10ˆ6 * 2ˆ63 causes panic in consensus due to overflow 28 Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

IF-EVMOS-09: Delegating 10ˆ6 * 2ˆ63 - x for a small x halts consensus 29 Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Involved artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Audit overview The Project In November 2021, Tharsis engaged Informal Systems to conduct a security audit over the documentation and the current state of the implementation of Ethermint/EVMOS. The EVMOS blockchain runs the Ethereum Virtual Machine on top of Cosmos SDK and Tendermint. It is able to deploy and execute Solidity contracts. One of the important features of EVMOS is that it can convert Cosmos-native coins into ERC20 tokens and back. This makes it possible to integrate Solidity contracts over ERC20 with Cosmos dApps. An important question is whether this conversion is safe.

Scope of this report The agreed-upon workplan consisted of the following tasks:

Audit the module intrarelayer (now called erc20)
Reproduce several bugs in the module staking
Audit the module evm This report covers the above tasks that were conducted November 15, 2021 through December 24, 2021, where cumulatively two person-weeks (80h) were spent by the following people at Informal Systems: • Igor Konnov: Principal Scientist • Jure Kukovec: Verification Engineer

Conducted work Over the Slack channel we shared documents with preliminary findings, which we discussed during online meetings. As a result of these discussions, we created issues only for those findings that the client considered important enough to be fixed. The other findings that do not require immediate action are marked as “discussed” in the report. For the intrarelayer and staking modules we proceeded with the stage of “Protocol reconstruction”, where we wrote TLA+ specifications by following the source code. These specifications capture the shape of available commands and their effects in a much more precise manner than the available documentation. Our TLA+ specifications contain hundreds of lines of code, in contrast to thousands of lines of code of the implementation. Having partially specified the protocols for intrarelayer and staking, we continued with “Adversarial testing”. To this end, we have specified potential invariants of the protocols, which we discussed with the Evmos team. With the model checker Apalache, we have produced protocol executions that violate such invariants. These executions were automatically run with Atomkraft against the blockchain, which was deployed in a single-node docker setup. For the evm module, we did selective manual code inspection and produced several Solidity contracts and integration tests. Due to our time budget, this analysis was not exhaustive. We have also reviewed the module descriptions of erc20 (called intrarelayer when the audit was done) and evm. For most of the issues, we have automatically generated end-to-end tests that are run in a Docker container. This makes the identified issues reproducible. None of them are false positives.

Timeline • November 15, 2021: Start of audit for the version v0.3.0 • December 24, 2021: End of audit for the version v0.4.0 • December 24, 2021: submission of the first draft of this report • February 01, 2022: submission of the second draft of this report

• May 3, 2022: confirming the status of the findings against version v3.0.0 • May 3, 2022: submission of the final report • November 16, 2022: all discovered issues have been resolved, the report is ready for publication

Conclusions We have not found any major implementation issues with the intrarelayer module. We have identified several potential security issues (all resolved): • IF-EVMOS-02: the module deploys several predefined contracts whose Solidity source code is not available. This has been resolved in v1.0.0. • IF-EVMOS-06: it is possible to register an ERC20-like contract which executes unexpected approvals and transfers under the standard ERC20 API. Although the registration requires a voting proposal by the validators, we stress that this voting procedure requires due diligence by the validators. This has been resolved to the extent possible. For the staking module, we have explored scenarios related to coin delegation, as EVMOS is using fixpoint precision that is different from the other Cosmos blockchains (18 digits after the decimal point in contrast to 6 digits after the decimal point, respectively). As a result, we have filed the findings IF-EVMOS-08 (resolved) and IF-EVMOS-09 (resolved) that are both exploiting the same issue when dealing with 64-bit integers in the delegation code. Although these attacks require a large amount of coins, the implications are severe enough to require attention. For instance, IF-EVMOS-09 halts the consensus engine. For the evm module, we have two findings: • IF-EVMOS-04: We have reproduced the scenario of a Solidity contract not self-destructing correctly, which was brought up to us by the EVMOS team (resolved). • IF-EVMOS-05: We have produced a contract that may consume vast amounts of gas. Its transactions are not properly processed by the blockchain (resolved). We have also reported minor issues. Due to restricted time budget, we should stress that our analysis is by no means exhaustive. The main audit efforts were done for the Evmos versions v0.3.0 and v0.4.0. For the versions v1.0.0 and v3.0.0, we only checked the status of our findings, but did not do any inspection beyond running the automatically produced tests, as outlined in the findings. We should note that the API between the versions v0.3.0 and v3.0.0 may have significantly changed. Although this was not a major issue for our Atomkraft tests, which we regenerated after updating the test driver in a few hours, this probably requires another audit.

Audit Dashboard Target Summary • Name: intrarelayer/erc20 and evm modules • Version: evmos v0.3.0 through v0.4.0 and ethermint v0.8.1 through v0.9.0 • Type: Implementation and preliminary documentation • Platform: Golang Engagement Summary • Dates: November 15 through December 24, 2021 • Method: Whitebox, model-based testing, symbolic model checking • Employees Engaged: 2 Fundings Summary by Severity and Difficulty

Severity Difficulty # Finding High Low 2 IF-EVMOS-04, IF-EVMOS-09 Potentially High High 2 IF-EVMOS-02, IF-EVMOS-06 Low Low 2 IF-EVMOS-03, IF-EVMOS-05 Informative Low 3 IF-EVMOS-01, IF-EVMOS-07, IF-EVMOS-08 Total 9

Severity Categories

Severity Description Informative The issue does not pose an immediate risk (it is subjective in nature); they are typically suggestions around best practices or readability Low The issue is objective in nature, but the security risk is relatively small or does not represent security vulnerability Medium The issue is a security vulnerability that may not be directly exploitable or may require certain complex conditions in order to be exploited High The issue is exploitable security vulnerability

Difficulty Categories

Difficulty Description Low Can be attacked by a user without special permission Medium Can be exploited without special permission with in-depth knowledge and control of the security architecture High Needs a collection of privileged users with in-depth knowledge and control of the security architecture

Engagement Goals This audit was scoped by the Informal Systems team in order to evaluate the correctness and security of the EVMOS blockchain. As the scope of the project is too large for the allocated time budget, we focused on potential attack scenarios by inspecting the code and running model-based tests.

Coverage Informal Systems manually reviewed the documentation and code of the software in the ethermint repository, starting at v0.8.1 and the evmos repository, starting at v0.3.0. As the code was updated during the review, we continued with further commits through v0.9.0 and v0.4.0 respectively. In the final stage, we checked our findings against Evmos v3.0.0. We focused on the code in the modules: intrarelayer (now erc20) and evm. As the two codebases cumulatively span over 39 kLOC of Golang code, we could not perform an exhaustive audit of the whole codebase.

Recommendations This section aggregates all the recommendations made during the audit. Short-term recommendations address the immediate causes of issues. Long-term recommendations pertain to the development process and long-term design goals. Our recommendations apply to the versions 0.3.0 and 0.4.0.

Short term • Improve user feedback/documentation. Issues IF-EVMOS-01, IF-EVMOS-03, IF-EVMOS-05, and IF- EVMOS-07 relate to user-feedback or expectations, and can be resolved by better error messages and/or documentation. • Make smart contracts transparent. Issue IF-EVMOS-02 highlights the use of bytecode JSON for the module-deployed smart contracts on EVM. To improve transparency, and allow for code review, the source code should be included in the repository and compiled at build-time. • Fix contract self-destruction. Issue IF-EVMOS-04 highlights incorrect behavior. • Safeguard against non-standard power reduction scenarios. Issues IF-EVMOS-08 and IF-EVMOS-09 highlight potential problems, which Tharsis cannot fix or affect at the source, and give recommendations on how to build around these limitations.

Long term • Raise awareness of arbitrary code in contracts. Issue IF-EVMOS-06 outlines security-critical scenarios, which relevant parties should be made aware of and take measures to prevent. These scenarios require a good understanding of both EVM and Cosmos. Since these contracts are subject to governance, Evmos should bring this to the attention of the delegators and validators. A contract can exchange ERC20 tokens for Cosmos coins, which may propagate via IBC. The implications of this have to be understood for each deployed contract (see the linked issue for concrete examples). The governance process requires due diligence. • Improve coverage by integration- and end-to-end testing. In addition to the reported issues, the integration tests could be improved to find issues like IF-EVMOS-04. The current integration tests have several TODOs and commented-out blocks.

Findings ID Title Severity Issue IF-EVMOS-04 A destructed contract High — resurrects in the next block IF-EVMOS-09 Delegating 10ˆ6 * 2ˆ63 High evmos #224

x for a small x halts consensus IF-EVMOS-02 Compile built-in contracts Potentially High evmos #140 in the build process IF-EVMOS-06 IERC20 Contracts may Potentially High — execute arbitrary code IF-EVMOS-03 convert-erc20 gas Low evmos #182 estimation is inaccurate IF-EVMOS-01 When a contract is Informative ethermint #783 deployed, the log contains plenty of error messages IF-EVMOS-07 Delegation and unbonding Informative — transfers rewards IF-EVMOS-08 Delegating over 10ˆ6 * Informative evmos #224 2ˆ63 causes panic in consensus due to overflow IF-EVMOS-05 No receipt for a contract Low evmos #1455 that stores lots of data

Severity Categories

IF-EVMOS-01: When a contract is deployed, the log con- tains plenty of error messages Severity Informative Type Implementation Difficulty Low Issue link Status Resolved

Surfaced from @informalsystems audit of Ethermint v0.8.1 and Evmos v0.3.0 OS: Linux in Docker

Resolution Fixed

Involved artifacts • statedb.go

Description When a simple ERC20 contract is deployed, e.g., by using hardhat, the evmosd log contains plenty of messages that look like follows: 8:03AM ERR account not found error="account evmos19q2kl5ctg0zszky4vferd78np3zgw5j8ew8tz8 does not exist: un 8:03AM ERR account not found error="account evmos138j4q4mc8eqsufwrurxhsmxtfwsenk6tur3t05 does not exist: un 8:03AM ERR account not found error="account evmos1vd2rjywyk8ald7rlrddwan9a709nyjnxa6pgez does not exist: un ... One of the addresses on that list is the address of the newly deployed contract. The other addresses are probably the addresses of the contracts that are extended by the new contract. It looks like this error message is produced either by GetNonce or SetNonce: https://github.com/tharsis/ethermint/blob/main/x/evm/keeper/statedb.go#L202-L268

Steps to reproduce Deploy a simple ERC20 contract with hardhat: // contracts/Hyperpyron.sol // SPDX-License-Identifier: MIT pragma solidity ˆ0.8.0;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

// This is a Hyperperon token. You cannot buy anything with it. // It is good for testing. contract Hyperpyron is ERC20 { constructor(uint256 initialSupply) ERC20("Hyperpyron", "HYPERPYRON") { _mint(msg.sender, initialSupply);

} }

Recommendation If this is expected behavior, do not print error messages in the log. If these messages have to be printed, make them more informative.

IF-EVMOS-02: Compile built-in contracts in the build pro- cess Severity Potentially High Type Implementation Difficulty High Issue link Status Resolved

Surfaced from @informalsystems audit of Ethermint v0.8.1 and Evmos v0.3.0

Resolution This issue has been addressed in the release v1.0.0 of Evmos. The contracts were compiled as part of the build process.

Involved artifacts • EVM contracts

Description Currently, the contracts are committed in the repository as JSON, that is, ABI and the bytecode. Given the debugging information, I believe that these contracts are simply compiled from openzeppelin Solidity code. However, it is impossible to tell what the contracts are doing without running bytecode analyzers. This is a potentially dangerous approach, as it would be hard to notice any severe change of behavior in the bytecode during peer review.

Recommendation Compile ERC20Burnable, ERC20MinterBurner, and ERC20PresetMinterPauser contracts from their Solidity sources as part of the build process. This would increase transparency of the built-in contracts and allow the developers to peer-review

Excerpt (19998 of 45287 characters). Read the whole page on informalsystems/audits ↗

← Back to Documentation