I examined the startRequestCancellation
and cancelRequest
functions. These functions are critical for allowing users to cancel pending requests, but something was missing: a nonce or unique identifier.
Without a nonce, each request could be vulnerable to replay attacks, just like the deposit function. An attacker could repeatedly call the cancel function, leading to unintended cancellations, disruptions, or even the loss of user assets.
Description: The absence of a nonce or unique identifier in request cancellations could allow an attacker to replay cancellation requests, leading to unauthorized or unintended cancellations.
Location: startRequestCancellation
and cancelRequest
functions in ethereum
/src
/IStarklane.sol
Issue: The startRequestCancellation
and cancelRequest
functions lack a nonce or unique identifier check for the requests. An attacker could potentially replay these functions, causing unintended cancellations.
Impact: Improper request cancellations could lead to loss of assets or service disruptions.
Tools used: Manual Review.
Recommendations: Add a nonce or unique identifier to requests to ensure that cancellations are valid and non-replayable.
Potential changes: I introduced a nonce mechanism to ensure each cancellation request was unique and could not be reused. This would prevent any replay attacks and ensure that the cancellation process was secure.
The process to cancel a message is detailed here: https://docs.starknet.io/architecture-and-concepts/network-architecture/messaging-mechanism/#l2-l1_message_cancellation Since `startRequestCancellation` has the `onlyOwner`, only the owner can begin that process.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.