Attacker can block LayerZero channel

[code423n4]

Lines of code

https://github.com/code-423n4/2022-05-velodrome/blob/main/contracts/contracts/redeem/RedemptionReceiver.sol#L72-L105

Vulnerability details

Impact

According to the LayerZero docs, the default behavior is that when a transaction on the destination application fails, the channel between the src and dst app is blocked. Before any new transactions can be executed, the failed transaction has to be retried until it succeeds.

See https://layerzero.gitbook.io/docs/faq/messaging-properties#message-ordering & https://layerzero.gitbook.io/docs/guides/advanced/nonblockinglzapp

So an attacker is able to initiate a transaction they know will fail to block the channel between FTM and Optimism. The RedemptionSender & Receiver won't be usable anymore.

Proof of Concept

The RedemptionReceiver contract doesn't implement the non-blocking approach as seen here: https://github.com/code-423n4/2022-05-velodrome/blob/main/contracts/contracts/redeem/RedemptionReceiver.sol#L72-L105

An example implementation of the non-blocking approach by LayerZero: https://github.com/LayerZero-Labs/solidity-examples/blob/main/contracts/lzApp/NonblockingLzApp.sol

Tools Used

none

Recommended Mitigation Steps

Use the non-blocking approach as described here

[pooltypes]

Duplicate of #87

[GalloDaSballo]

@pooltypes Can anyone send a message or would they need to be whitelisted?

[GalloDaSballo]

If anyone can call and deny, the contract is not suited to handle exceptions and doesn't implement the forceReceive function, meaning the channel can be griefed and I don't believe there's a way to remedy.

The contract needs to implement forceResumeReceive to allow to remove malicious messages that may be received

I still am unsure if anyone can send a malicious message or if they need to be approved

[GalloDaSballo]

If only the admin can this is a Medium Severity, if anyone can, this is a High Severity finding

[GalloDaSballo]

From the documentation it seems like anyone can call the function:
https://layerzero.gitbook.io/docs/guides/master/how-to-send-a-message

[GalloDaSballo]

With the information that I have it seems like anyone can grief the endpoint making claims revert indefinitely, have reached out to the sponsor as well as LayerZero but have yet to receive any reply

[GalloDaSballo]

With the information I currently have, it seems like the channel can be setup to receive messages only by the specified contract, however for multiple reasons, the message sent can cause a revert, and in lack of a "nonblocking" architecture, the messages can get stuck indefinitely.

However, the implementation under scope has none of these defenses, it seems like the contact under scope can be denied functionality by any caller that builds their own LZApp

See example of how to prevent untrusted callers:
https://github.com/LayerZero-Labs/solidity-examples/blob/e46a95ce93347aa65680bef288e206af0e5a8917/contracts/lzApp/LzApp.sol#L28

Because of that, the message queue can be filled with blocking messages that cannot be removed.

Because the contract under scope also has no way of re-setting the queue, I have reason to believe that any attack can permanently brick the receiver.

For these reasons, I believe High Severity to be more appropriate

[ethzoomer]

At this point in time we've already completed all of the redemptions

Is it possible to send a message from the contract other than what sender sends? lz's msg queues are per src addr. https://layerzero.gitbook.io/docs/faq/messaging-properties
"STORED message will block the delivery of any future message from srcUA to all dstUA on the same destination chain and can be retried until the message becomes SUCCESS"
The only way that can get gummed up is if redemption's over right?

[GalloDaSballo]

My understanding is any sender can block the queue as the receiver will revert

That said if redemption is over, there's no loss beside the risk of burning funds from the FTM side