Panic in MustUnmarshal

[howlbot-integration[bot]]

Lines of code

https://github.com/b-harvest/ethermint/blob/dudong2/feat/cosmos-sdk%40v0.50.x-cometbft%40v0.38.0-2/x/evm/types/msg.go#L464 https://github.com/b-harvest/ethermint/blob/dudong2/feat/cosmos-sdk%40v0.50.x-cometbft%40v0.38.0-2/x/evm/types/msg.go#L471 https://github.com/b-harvest/ethermint/blob/dudong2/feat/cosmos-sdk%40v0.50.x-cometbft%40v0.38.0-2/x/evm/types/msg.go#L478

Vulnerability details

Impact

The ModuleCdc is only strictly used for testing, as stated in https://github.com/b-harvest/ethermint/blob/dudong2/feat/cosmos-sdk%40v0.50.x-cometbft%40v0.38.0-2/x/evm/types/codec.go#L30-L32.

eventhough the usage of ModuleCdc itself is harmless, this can be used to DOS the node by leveraging the fact that MustUnmarshal is being used by ModuleCdc.

MustUnmarshal is very strict and it's going to panic when it fails to unmarshal the data, which we can see in this code https://github.com/cosmos/cosmos-sdk/blob/main/codec/proto_codec.go#L108-L115.

Proof of Concept

example snippet of the POC

"@type": "/ethermint.evm.v1.MsgEthereumTx", "data": { "@type": "/ethermint.evm.v1.DynamicFeeTx", //the data below is the legacyTX fields, However, we defined the @type as a DynamicFeeTx "nonce": "8", "gas_price": "7", "gas": "999999999999", "to": "0x60DD27A3FbB76e158F6e7EE4F1FB926a052CF2ab", "value": "0", "data": "qSEAyw==", "v": "BjY=", "r": "qaJ6tUAIqPQ/neu+fYXEeWoCJtwnssAd9jLbQ2ee/u4=", "s": "JFSlZnGfL/jqBnDjVvmqbGZ+Qt4Mnr03wqRIPKNALtM=" },

Tools Used

manual

Recommended Mitigation Steps

as stated in the https://github.com/cosmos/cosmos-sdk/blob/main/codec/proto_codec.go#L108-L115. to dynamicly handle errors during data unmarshaling, please use UnmarshalInterface function, and handle the error properly, instead of panicking.

Assessed type

DoS

[poorphd]

• Labels

  • sponsor disputed

• Reasoning: un-reachable code

  • If the Ethereum Transaction Type field is set incorrectly, it won't reach GetMsgEthereumTxFromMsgV2. If it does reach GetMsgEthereumTxFromMsgV2, the transaction has already passed the validity checks.
  • When a transaction is sent to a Cosmos SDK-based chain, the CheckTx process is initiated. Internally, CheckTx calls runTx. GetMsgEthereumTxFromMsgV2 is triggered at tx.GetMsgsV2(line 946) in runTx. Prior to this line, the Transaction undergoes a validation check at validateBasicTxMsgs(lines 874-876).

  • validateBasicTxMsgs validates each message within the Cosmos Tx by calling the message type's Validate method.

    

• Severity

  • Mid → Not valid
  • In the provided scenario, where the Type is DynamicTx but includes a Legacy field, it will be rejected by DynamicFeeTx.Validate. If filtered out here, it can't reach tx.GetMsgsV2(line 946), where it could potentially cause an issue.
  • To confirm the issue raised, the issuer needs to provide an invalid message that can indeed reach tx.GetMsgsV2.

[3docSec]

Marking as not satisfactory:

• the report does not provide evidence that a panic can actually happen
• the report does not contain any link to the instance(s) in question

[c4-judge]

3docSec marked the issue as unsatisfactory: Insufficient proof