TimeoutTimeStamp and TimeoutHeight fields are not properly validated

[code423n4]

Lines of code

https://github.com/code-423n4/2023-06-canto/blob/a4ff2fd2e67e77e36528fad99f9d88149a5e8532/Canto/x/onboarding/keeper/ibc_callbacks.go#L40

Vulnerability details

Impact

The absence of proper validation for TimeoutTimeStamp and TimeoutHeight fields before processing an onboarding request can lead to significant disruption and potential security risks.

This might allow an attacker to send an IBC (Inter-Blockchain Communication) packet that will never time out, leading to the packet being stuck indefinitely in the receiving module. This could result in resource exhaustion on the receiving end, as these packets could accumulate over time, using up storage space, and potentially impacting the performance of the system as well as the overall throughput of the IBC protocol.

Furthermore, this could be exploited as part of a wider Denial of Service (DoS) attack, where an attacker could deliberately send a high number of such packets, exacerbating the aforementioned impact.

Additionally, the failure to validate these fields might allow the transmission of outdated or irrelevant transactions. For example, transactions that should have timed out due to changes in market conditions or other related factors could be processed

Proof of Concept

According to

https://tutorials.cosmos.network/academy/3-ibc/3-channels.html

the packet definition is:

interface Packet {
  sequence: uint64
  timeoutHeight: Height
  timeoutTimestamp: uint64
  sourcePort: Identifier
  sourceChannel: Identifier
  destPort: Identifier
  destChannel: Identifier
  data: bytes
}

TimeoutTimestamp and TimeoutHeight (pick one of these) dictate the time before which the receiving module must process a packet.

According to

https://github.com/cosmos/ibc/tree/main/spec/core/ics-004-channel-and-packet-semantics#definitions

The timeoutHeight indicates a consensus height on the destination chain after which the packet will no longer be processed, and will instead count as having timed-out.

The timeoutTimestamp indicates a timestamp on the destination chain after which the packet will no longer be processed, and will instead count as having timed-out.

However, in the callback code

the TimeoutTimeStamp or TimeoutHeight is never validated before processing the callback request to swap and convert

Tools Used

N/A

Recommended Mitigation Steps

Validate either TimeOutStamp or TimeOutHeight before processing the onboard request

Assessed type

Timing

[c4-pre-sort]

JeffCX marked the issue as primary issue

[tkkwon1998]

This issue is out of scope since it deals with the standard IBC module, which is used throughout the entire cosmos ecosystem.

Also, although I haven't dug deeper to validate the issue, I would be very surprised if there wasn't a check somewhere. I imagine it may exist in the relayer software.

[c4-sponsor]

tkkwon1998 marked the issue as sponsor disputed

[c4-judge]

0xean marked the issue as unsatisfactory: Out of scope