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
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
N/A
Validate either TimeOutStamp or TimeOutHeight before processing the onboard request
Timing
The text was updated successfully, but these errors were encountered:
All reactions