Lack of validation in InitializeMessageRecoveryCommand may lead to non-inclusion proof

[ishantiw]

Description

Due to a lack of validation, the InitializeMessageRecoveryCommand can receive the params.channel parameter as an empty string. An empty string on the value field of a query, makes the SparseMerkleTree's verify method perform a non-inclusion proof instead of an inclusion proof. So, by providing the empty string for params.channel, a user can prove that there exists a channel between the terminated chain and the chain receiving the message on the terminated chain's stateRoot, when one does not exist (technically the user proves that it does not exist, but the valid boolean will return true).

https://github.com/LiskHQ/lisk-sdk/blob/89e7504ef5eb6183aefe576a93be3d6052e56038/framework/src/modules/interoperability/mainchain/commands/initialize_message_recovery.ts#L112-L122

This finding is of informational severity because while it bypasses the goal of the command's verification, the execute method will fail on codec.decode<ChannelData>(channelSchema, params.channel) because param.channel is an empty string and cannot be decoded. It is, however, a reminder that it may be a bad design choice to have the SparseMerkleTree's verify function support both inclusion and non-inclusion proofs depending on the query value.

Affected version

v6.0.0-beta.2

[mitsuaki-u]

Refer to: Issue # 116 on lisk-db for updates to Sparse Merkle Tree interface