GHSA-3fp5-2xwh-fxm6: Evmos transaction execution not accounting for all state transition after interaction with precompiles
Context[`stateObject`](https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/state_object.go#L53-L68): represents the state of an account and is used to store its updates during a state transition. This is accomplished using two in memory Storage variables: `originStorage` and `dirtyStorage`[`StateDB`](https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/statedb.go#L33-L55): it is the general interface to retrieve accounts and holds a map of stateObjects.ImpactAn external contributor, @iczc, discovered a way to mint arbitrary tokens due to the possibility to have two different states not in sync during the execution of a transaction. The exploit is based on the fact that to sync the Cosmos SDK state and the EVM one, we rely on the `stateDB.Commit()` method. When we call this method, we iterate though all the `dirtyStorage` and, **if and only if** it is different than the `originStorage`, we [set the new state](https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/statedb.go#L460-L465). Setting the new state means we update the Cosmos SDK KVStore.Below, are described the steps to perform the attack:User send a tx to a smart contract (SC) that is calling a precompile.The SC perform a state transition of its state from A to B.The SC call the precompile.The SC perform a state transition of its state from B to A (revert of the previous).Once the transaction is executed, and the final **Commit** is performed, the state A will not be committed to the store because A is the same as `originStorage`.If the tx is executed correctly, this is what happens at the store level:Initial state A is loaded from the KVStore and the dirtyStorage is set to B.Before running the precompile, the `dirtyStorage` is committed to the KVStore without changing the `originStorage`.Now, since we have a `dirtyStorage`, it is updated to the previous value A without changing the `originStorage`.Since the tx executed correctly, the evm calls the commit to persist the dirtyStorage. However, since dirtyStorage is equal to originStorage, nothing will be changed.To summarize, if a contract storage state that is the same before and after a transaction, but is changed during the transaction and can call an external contract after the change, it can be exploited to make the transaction similar to non-atomic. The vulnerability is **critical** since this could lead to drain of funds through creative SC interactions.SeverityBased on [ImmuneFi Severity Classification System](https://immunefisupport.zendesk.com/hc/en-us/articles/13332717597585-Severity-Classification-System) the severity was evaluated to `Critical` since the attack could have lead to direct loss of funds.PatchesThe issue has been patched in versions >=V17.0.0.For more informationIf you have any questions or comments about this advisory:Reach out to the Core Team in [Discord](https://discord.gg/evmos)
Open a discussion in [evmos/evmos](https://github.com/evmos/evmos/discussions)
Email us at [security@evmos.org](mailto:security@evmos.org) for security questions
CVSS v3.1: 9.1