Lucene search

K
code423n4Code4renaCODE423N4:2023-06-CANTO-FINDINGS-ISSUES-65
HistoryJun 23, 2023 - 12:00 a.m.

TimeoutTimeStamp and TimeoutHeight fields are not properly validated

2023-06-2300:00:00
Code4rena
github.com
4
timeouttimestamp
timeoutheight
validation
dos attack
resource exhaustion
outdated transaction
ibc protocol

Lines of code

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&gt;

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


The text was updated successfully, but these errors were encountered:

All reactions