Boost _ Folks Finance 33652 - [Smart Contract - Insight] BridgeRouters Unprotected Reversal Function Compromises User Control
Submitted on Thu Jul 25 2024 15:22:10 GMT-0400 (Atlantic Standard Time) by @A2Security for Boost | Folks Finance
Report ID: #33652
Report type: Smart Contract
Report severity: Insight
Target: https://testnet.snowtrace.io/address/0xa9491a1f4f058832e5742b76eE3f1F1fD7bb6837
Impacts:
Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)
Description
Brief/Intro
The BridgeRouter
system allows unauthorized reversal of failed transactions, enabling attackers to disrupt operations and force users to incur unnecessary costs. This vulnerability could lead to financial losses, prevent legitimate transactions.
Vulnerability Details
The reverse message functionality in the
BridgeRouter
system is designed to cancle failed cross-chain messages. Here's how it operates:
When a message fails during execution on the destination chain, it's stored in the
BridgeRouter
contract as a failed message.The
reverseMessage
function in theBridgeRouter
can be called with the adapterId and messageId of the failed message: `This function retrieves the failed message, clears it from storage, and calls the
reverseMessage
function on the corresponding handler (typically the Hub contract).
In the Hub contract, the
_reverseMessage
function processes the reversal:The Hub verifies the token receipt from the original transaction and initiates a token return to the user on the source chain.
To complete the reversal, the Hub calls back to the BridgeRouter to send a cross-chain message returning the tokens.
The
BridgeRouter
sends this cross-chain message, using fees from the balance associated with the original user'saccountId
.
The core issue lies in the lack of propore access control and the ability for anyone to call the
reverseMessage()
function inbridgeRouter
contract for any failed messages (for allowed actions like deposit/repay ..ect), usurping the rightful decision-making power of the original message sender:
This vulnerability allows malicious actors to force the reversal of transactions against the wishes of the original sender This is problematic for various reasons:
User Autonomy: The users who initiate cross-chain messages are the only ones who should have the authority to decide whether to retry or reverse a failed message. They have the context of their intended operation and are best positioned to make this decision. Moreover, they bear the financial consequences of both the initial transaction and any subsequent actions.
Financial Implications: When a reversal is initiated, the fees for the return message are deducted from the user's balance in the BridgeRouter. This can lead to unexpected costs for the user, especially if the reversal is to a high-fee network like Ethereum mainnet.
Exploitation of Failed Transactions: Even in cases where a transaction fails due to easily rectifiable issues (like slightly insufficient gas), an attacker can force a costly reversal instead of allowing a simple retry.
Smart Contract integration: Contracts interacting with this system may not be designed to handle unexpected reversals, potentially leading to locked funds or corrupted contract states.
The lack of restrictions on who can call
reverseMessage()
and the absence of a mechanism to prioritize the original sender's intentions make this a severe vulnerability in the current system design.
Impact Details
This vulnerability allows malicious users to reverse transactions sent by others, even if those transactions are retryable. When a transaction is reversed:
The original user loses the cost of sending the initial transaction from the spoke chain.
The user incurs the cost of reversing the transaction, which is deducted from their balance on the hub chain.
Users lose control over the decision to retry or reverse their transactions.
For actions that allow reversal, users can be griefed, preventing them from ever successfully retrying their transactions.
The attacker only needs to pay gas fees on the hub chain (Avalanche), which are relatively cheap. This creates an asymmetric situation where the attacker can cause significant financial damage to users at a low cost to themselves, potentially disrupting the entire cross-chain messaging system.
References
BridgeRouter.sol
Hub.sol
SpokeToken.sol
CCIPTokenAdapter.sol
Proof of concept
Proof of Concept
We have added a proof of concept, in foundry that forks avalanche fugi and interacts with the deployed version of the protocol in testnet. To run the proof of concept please add the following files under tests. Please also make sure foundry is initialized in the project, and declare the custom remapping @forge-std
First FIle: test/pocs/base_test.sol