LayerZero is a universal cross chain messaging (CCM) protocol. By having a LayerZero smart contract deployed on a chain, assets can be transferred between chains. A relayer is an entity that submits cross chain transactions. A particular user application can choose the relayer and oracle they would like to use.
The author goes through a
previous vulnerability within LayerZero. In this post, the author noticed that when emitting an event the relayer address was not being included. So, they were curious if there were implications for this.
By setting the price fee to be 0 on their own oracle/relayer then switching to the default LayerZero versions, zero fees will be incurred. Being able to not pay fees is bad. Interesting bug by itself!
While trying to address this issue a modification was made to the protocol. When calling setConfig() function to update the oracle/relayer information, the relayer should refrain from relaying the message on this same block.
The relayer failed to check who sent the update to the configuration. If an attacker sends a message to a regular UA then a malicious UA calls setConfig() within the same transaction then the message will not be relayed.
This is very severe! The outbound nonce is incremented with each message, making it not possible to get the message relayed with more time. Originally, they reported this as a critical vulnerability. However, the development team has a way to force send transactions that were not originally relayed, bumping this to a medium severity bug.
A good design from the LayerZero team! I like to think they thought of threats and came up with solutions for many of these threats. In this case, they probably thought about a relayer not processing a message, dropping it entirely to build out this solution. Smart design of protocols creates situations where critical vulnerbailities are now recoverable, which is super cool.