Submitted by Bauchibred, also found by Sentryx and 0x007
The Nibiru EVM modules token conversion mechanism contains a critical vulnerability when handling rebasing tokens. The issue stems from an incorrect assumption about the 1:1 relationship between escrowed ERC20 tokens and their bank coin representations, which can be violated when token balances change outside of transfers (e.g., through rebasing) and these type of tokens are supported by Nibiru.
The Nibiru EVM module supports converting ERC20 tokens to bank coins and vice versa. When converting from ERC20 to bank coins, the tokens are escrowed in the EVM module, and when converting back, these escrowed tokens are used to fulfill the conversion.
This logic can be seen in the ConvertCoinToEvm, convertCoinToEvmBornERC20 and convertEvmToCoin functions in the msg_server.go file, see x/evm/keeper/msg_server.go#L486-L561.
The conversion mechanism assumes a static 1:1 relationship between escrowed ERC20 tokens and bank coins, as evidenced in the convertCoinToEvmBornERC20 function that is used when converting the bank coins back to its ERC20 representation:
See here:
Evidently, Nibiru makes a critical assumption (invariant) about token availability as shown in the snippet above.
However, this assumption would be incorrect for some supported tokens like rebasing tokens, which have been hinted to be used by Nibiru as shown in the README:
README.md#L129-L137
This is because for tokens that have their balance changes not necessarily through transfers, and are rebasing in nature there would be multiple rebases while the tokens are escrowed after the initial conversion from ERC20 to Bank Coin; which would then mean that by the time there is an attempt to convert the tokens back to ERC20, the balance of the tokens in the escrow would have changed (positively/negatively) completely sidestepping the invariant of 1:1 relationship between escrowed ERC20 tokens and their bank coin representations.
This bug case completely breaks the subtle invariant of 1:1 relationship between escrowed ERC20 tokens and their bank coin representations. In our case, the issue manifests itself in the following two scenarios:
Consider not supporting these type of tokens at all or instead provide a mechanism to handle balance changes in the escrow/EVM module.
berndartmueller (judge) decreased severity to Medium:
Unique-Divine (Nibiru) disputed and commented:
berndartmueller (judge) commented:
Bauchibred (warden) commented:
berndartmueller (judge) commented:
