Implications of invalid encoded extrinsic calls

Question

We are seeing the following error whenever an invalidly encoded but properly signed extrinsic is submitted in our substrate based chain.

{
    "jsonrpc": "2.0",
    "error": {
        "code": 1002,
        "message": "Verification Error: Runtime error: Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed\nWASM backtrace:\n\n    0: 0x2011df - <unknown>!rust_begin_unwind\n    1: 0x9a20 - <unknown>!core::panicking::panic_fmt::h57b56b1dc717ba48\n    2: 0x1c763d - <unknown>!TaggedTransactionQueue_validate_transaction\n",
        "data": "RuntimeApi(\"Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed\\nWASM backtrace:\\n\\n    0: 0x2011df - <unknown>!rust_begin_unwind\\n    1: 0x9a20 - <unknown>!core::panicking::panic_fmt::h57b56b1dc717ba48\\n    2: 0x1c763d - <unknown>!TaggedTransactionQueue_validate_transaction\\n\")"
    },
    "id": 55
}

As it's shown in the error, it looks like that the extrinsic decoding code inside WASM panics and throws this wasm trap error that is caught by the Node.

Some of our questions and concerns are as following:

• What are the security implications of panicking inside the WASM when an extrinsic can not get decoded successfully? And if this might expose any new attack surface.
• Are there any plans to handle these decoding errors more gracefully?

Answer 1

Great question!

What are the security implications of panicking inside the WASM when an extrinsic can not get decoded successfully?

Before a transaction enters the tx pool the tx is validated using the runtime’s fn validate_transaction. If it panics, the tx is immediately dropped and not gossiped to the rest of the network. Hence, when a tx is incorrectly encoded it can’t DoS the network because it panics in fn validate_transaction (my guess is here called here).

In general, panics in the runtime should be prevented at all costs. When a malicious transaction enters the tx pool, it will be gossiped to other nodes and can be added to a block. All the nodes will provide computation power, but because it panics, the work was done for nothing and nobody paid for it. In other words, congesting the network for free, aka a Denial of Service (DoS) attack vector.

(Great resource about the validation of a tx before entering the tx pool can be found here)

Are there any plans to handle these decoding errors more gracefully?

There's not much that can be done on the node side since it has to assume an adversarial network model, where nodes cannot trust the inputs.

However, perhaps a relevant issue: https://github.com/paritytech/substrate/issues/10585