The Starklane Messaging contract contains a critical vulnerability that exposes it to replay attacks, which could compromise the security and integrity of the entire messaging system.
This stems from the absence of message expiration and reuse prevention mechanisms, allowing malicious actors to potentially exploit the system through replay attacks.
The Starklane Messaging contract relies heavily on the IStarknetMessaging
interface to facilitate communication between Layer 1 (Ethereum) and Layer 2 (Starknet).
However, the current implementation lacks essential security measures to prevent message replay attacks, which could lead to severe consequences.
Lack of Nonce Tracking: The contract does not implement any mechanism to track unique messages, making it vulnerable to message reuse .
Absence of Expiration Checks: There are no built-in expiration mechanisms for messages, allowing old messages to potentially be processed repeatedly [2][4].
Potential for Unauthorized Actions: Without proper safeguards, malicious actors could exploit the system by reusing previously consumed messages, leading to unauthorized actions or transfers .
Double Spending Risk: The lack of uniqueness tracking increases the risk of double spending in token transfer scenarios .
System Integrity Compromise: The integrity of the messaging system itself could be compromised, affecting overall trust and functionality of the contract .
Unauthorized Actions: Malicious actors could potentially perform unauthorized withdrawals or transfers by reusing previously consumed messages .
Double Spending: The same message could be used multiple times, leading to double-spending in token transfer scenarios .
System Integrity Risk: The integrity of the messaging system could be compromised, resulting in financial loss and erosion of user trust .
Long-term Vulnerability: This issue persists over time unless addressed, allowing continuous exploitation attempts .
Manual Code Review
Static Analysis Tools
To address this critical vulnerability, the following mitigations are necessary:
Nonce Tracking: Implementing a nonce parameter ensures each message is unique and can only be processed once .
Expiration Checks: Adding timestamp-based expiration logic prevents old messages from being consumed after a certain period.
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.