Same Contract Multi Permits fundamentally cannot be solved via the chosen standards

[c4-bot-1]

Lines of code

https://github.com/Tapioca-DAO/tapioca-periph/blob/2ddbcb1cde03b548e13421b2dba66435d2ac8eb5/contracts/tapiocaOmnichainEngine/extension/TapiocaOmnichainExtExec.sol#L40-L41

Vulnerability details

Impact

The finding is a direct follow up to: All cross-chain USDO and TOFT flows using approvals may be susceptible to permit-based DoS griefing from the spearbit report

Since permits are signatures, they will be available to anyone monitoring the chain

And they will be usable by anyone, since the goal of permit is allowing some other msg.sender to broadcast the signature and have it work

POC

Due to this, the current architecture is still subject to front-run exploits via the following:

• Monitor the mempool for any sequence of permit signatures
• Execute all of the signatures before the transaction

Any time, more than one permit is signed to the same token, for example to Add Exact Allowance and Revoke it, front-running the calls will burn the approvals and reset the allowance down to 0.

The transaction, which may have worked had only one of the signatures been front-run, is unable to function as the last signature for revoking will be broadcasted right after the first one

This effectively means that the only architecture that could be used for Tapioca is single signature, with no revokes

Which doesn't seem to be the case at this time

Mitigation

The only solution I have found at this time would be to use Permits to grant approvals (with try-catch)

And not using permits to revoke approvals, as the revoke permit call could be front-run causing all xChain calls to revert

If you wish to use exact approvals xChain, which I recommend, you'd have to solve for rounding errors when converting shares vs amounts.

Due to this, you may recommend people to grant higher allowances, and then change all toft tokens to have a renounceAllowance function which would re-set the allowance on behalf of the operator, enforcing a strict 0 -> X -> 0 allowance pattern while avoiding front-run griefs.

This would ensure that trusted Tapioca Operators receive allowances, and re-set them at the end of all of their operations, which gives a stronger security guarantee.

We built something similar for eBTC, with PositionMangers: https://github.com/ebtc-protocol/ebtc/blob/3406f0d88ac9935da53f7371fb078d11c066802e/packages/contracts/contracts/Interfaces/IPositionManagers.sol#L30

Assessed type

MEV

[c4-judge]

dmvt marked the issue as duplicate of #83

[c4-judge]

dmvt marked the issue as satisfactory

[c4-judge]

dmvt marked the issue as not a duplicate

[c4-judge]

dmvt marked the issue as selected for report

[c4-judge]

dmvt marked the issue as primary issue