EOS EVM v0.5.2 Release Notes
This release fixes several security vulnerabilities discovered in EOS EVM Contract and EOS EVM Node.
Components
EOS EVM Contract
Prevent account ID reuse
The use of available_primary_key from multi_index to determine the internal account ID of a new EVM account was undesirable because that internal account ID would be reused by new EVM account after the previous account that was using that ID destroyed itself via the SELFDESTRUCT EVM opcode.
But this undesired behavior actually was a security issue due to another design decision in EOS EVM Contract to delay clean up of contract account state to later calls of the gc action; this design decision needed to be made due to the limitation that EOS transaction execution time is tightly bounded but the same is not true for the number of storage slots that an EVM contract may have accumulated over time. The design of delaying garbage collection of a self-destructed contract storage for later was safe under the assumption that internal account IDs would never be reused. Unfortunately, due to the way internal account IDs for new accounts were generated, that assumption did not hold.
The fix to the security issue is actually very simple: keep track of the next internal account ID to use and increment it after create a new account. This change fixes the security issue for the EOS EVM Contract going forward.
However, the bug could easily be triggered (even inadvertently) causing a newly deployed EVM contract to inherit the state of an unrelated EVM contract that self-destructed earlier. One caveat is that no new externally-owned accounts would need to be created between the self-destruction of one contract and the creation of a new contract account. Unfortunately, both mainnet and testnet had at least one account that triggered the undesired state inheritance side-effect which led to deviations in EVM state from what was intended y the EVM protocol.
So, this security release also includes new administrative actions to correct aspects of the EVM state.
Note: The administrative actions have already been used to correct unwanted state differences on both testnet and mainnet. Additionally, the account ID reuse bug has already been patched on both testnet and mainnet.
Admin actions to correct state in EOS EVM
It is always possible for issues to arise due to bugs within the EOS EVM Contract that causes it to deviate from the intended behavior of the EVM protocol. This can lead to the state in the contract deviating from what it should be and deviating from what the state in the EOS EVM Node. So, it is desirable to have administrative actions, which can only be used by the same authority that can change the code of the EOS EVM Contract, to correct faulty state.
This deviation of state already occurred on both testnet and mainnet from transactions that inadvertently triggered the undesired state inheritance side-effect due to the account ID reuse bug mentioned above. So some of the admin actions introduced in this release were essential for properly resolving the impact due to security bug on both testnet and mainnet. This is also why these admin actions were introduced in the security patch despite technically being a new feature and not a bug fix.
EOS EVM Node and RPC
Correct processing of pushtx actions in ship_receiver_plugin
A bug was identified in EOS EVM Node which could cause it to process a different sequence of EVM transactions than the one processed by the EOS EVM Contract.
Because the state computed by EOS EVM Node is used by EOS EVM RPC to process read requests for the EOS EVM state (e.g. executing view functions), it is possible that vulnerable EOS EVM Nodes could provide responses that deviate from the intended result that would be computed by EOS EVM Contract (e.g. via its exec function).
It is critical that operators of EOS EVM Node upgrade their software to avoid returning incorrect responses to read requests. A proper upgrade to fix this issue requires that EOS EVM Node replay the virtual blockchain generated from genesis of EOS EVM.
Note: The EOS EVM Nodes operated by the ENF which serve the RPC requests to the https://api.evm.eosnetwork.com/ (for mainnet) and https://api.testnet.evm.eosnetwork.com/ (for testnet) endpoints have already been upgraded.
Feature lifecycle updates
Deprecations
TX-Wrapper
TX-Wrapper has been deprecated with plans to remove and replace with eos-evm-miner for the release of EOS EVM v0.6.0.
Building, compatibility, and upgrading
Building
The README in the eos-evm repository contains instructions on how to build the components.
Compatibility and upgrading
The components can be upgraded from the 0.5.0 and 0.5.1 releases.
EOS EVM Node binaries should be replaced and relaunched with a full replay from the EOS EVM genesis.
Assuming the state inheritance side-effect has not been triggered on the target network, the EOS EVM Contract can be upgraded by deploying the new WASM and ABI and then creating a new account. On a fresh network, simply deploying the contract with the fix is sufficient and there is no need to even create the new account.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
Full Changelog: v0.5.1...v0.5.2
