Bridges can be frontrun by malicious actors and change the address on the destination chain to its address. Front running can be done either by sending a tx with a higher gas price (usually tx are ordered in a block by the gas price / total fee), or by paying an additional fee to the validator if they manage to run their tx without reverting.
When a user bridges, there are 2 main stages, the first is transferring the token and the second is sending a message that functions to execute the function on the destination chain. The thing that can cause all bridges to be hit by a frontrun attack is that the main function CrossDomainMessanger::sendMessage() has no modifier or in other words, everyone can call that function, crafting a message from the user who bridges and changing the destination address to their own, then sending a message to finalize the bridge process on the destination chain.
This applies to all tokens and also applies to bridges from L1 to L2 or from L2 to L1 :
Alice call bridgeERC20() / bridgeERC20To(), then continued with the _initiateBridgeERC20() function
Bob as a malicious actor listens to mempool in order to check if he sees a tx of Alice bridge
Then Bob calls the CrossDomainMessanger::sendMessage() function on the source chain, crafts all the data Alice gave, and replaces the destination address on the destination chain with the address he has
Bob pays a higher gas price so that his tx is executed before sendMessage on Alice's tx.
Bob can finalize on the destination chain and get the tokens bridged by Alice.
0xDemon
High
Bridges can be frontrun by malicious actors
Summary
Bridges can be frontrun by malicious actors and change the address on the destination chain to its address. Front running can be done either by sending a tx with a higher gas price (usually tx are ordered in a block by the gas price / total fee), or by paying an additional fee to the validator if they manage to run their tx without reverting.
When a user bridges, there are 2 main stages, the first is transferring the token and the second is sending a message that functions to execute the function on the destination chain. The thing that can cause all bridges to be hit by a frontrun attack is that the main function
CrossDomainMessanger::sendMessage()has no modifier or in other words, everyone can call that function, crafting a message from the user who bridges and changing the destination address to their own, then sending a message to finalize the bridge process on the destination chain.This applies to all tokens and also applies to bridges from L1 to L2 or from L2 to L1 :
Root Cause
In CrossDomainMessenger.sol:176 there is a missing modifier for anyone who can call this function
Internal pre-conditions
No response
External pre-conditions
No response
Attack Path
ERC20 bridge as an example from L1 to L2 :
bridgeERC20()/bridgeERC20To(), then continued with the_initiateBridgeERC20()functionCrossDomainMessanger::sendMessage()function on the source chain, crafts all the data Alice gave, and replaces the destination address on the destination chain with the address he hassendMessageon Alice's tx.Impact
User loses all the tokens she / he bridged
PoC
Mitigation
Consider adding modifiers on
CrossDomainMessanger::sendMessage()(i.eonlyBridge)