Closed c4-bot-5 closed 6 months ago
dmvt marked the issue as primary issue
Note to judge: Sponsor confirmed label via #134
dmvt marked the issue as duplicate of #134
dmvt marked the issue as satisfactory
dmvt marked the issue as duplicate of #81
Lines of code
https://github.com/Tapioca-DAO/tapioca-periph/blob/032396f701be935b04a7e5cf3cb40a0136259dbc/contracts/tapiocaOmnichainEngine/TapiocaOmnichainReceiver.sol#L300-L317 https://github.com/Tapioca-DAO/tapioca-periph/blob/032396f701be935b04a7e5cf3cb40a0136259dbc/contracts/tapiocaOmnichainEngine/extension/TapiocaOmnichainExtExec.sol#L59-L67
Vulnerability details
Description
The Tapioca protocol facilitates multiple LayerZero composed messages by concatenating them into a single message and executing all of them within the
TapiocaOmnichainReceiver.lzCompose()
function.There are various types of composed messages supported by Tapioca, one of which is the permit message (
msgType = [500, 505]
). These messages are executed through the internal functionTapiocaOmnichainReceiver._extExec()
corresponding to the token type required by the sender.However, the permit transaction can be executed by anyone, not just the
TapiocaOmnichainReceiver
contract. Consequently, an attacker can front-run the permit() call before the execution of the permit message from thelzCompose()
function. This results in a revert on the compose message transaction due to the token approval already being granted (increasing the permit nonce of the token). As a result, none of the messages encoded in the composed message with the permit messages, will be executed.Impact
DoS attacks can be launched against composed messages that include permit messages.
Tools Used
Manual review
Recommended Mitigation Steps
Consider implementing a low-level call to handle the success of the permit function. If the permit function fails, you can then proceed to the next message instead of reverting the transaction.
Assessed type
Timing