Decent - imare's results

Lines of code

https://github.com/code-423n4/2024-01-decent/blob/011f62059f3a0b1f3577c8ccd1140f0cf3e7bb29/src/bridge_adapters/DecentBridgeAdapter.sol#L127-L139 https://github.com/code-423n4/2024-01-decent/blob/011f62059f3a0b1f3577c8ccd1140f0cf3e7bb29/src/bridge_adapters/StargateBridgeAdapter.sol#L183-L207

Vulnerability details

Tokens are left in the bridge when the swap at the destination chain fails

Impact

When tokens are bridged trough the bridge (DecentBridgeAdapter and StargateBridgeAdapter) they can be left in them if the swap in the UTB#receiveFromBridge fails.

Proof of Concept

Both bridges suffers from the same problem. When tokens arrive at the main bridge contract callback the swap can fail leaving the user without funds which are now locked inside the protocol:

When token are bridged trough DecentBridgeAdapter#receiveFromBridge this contract has an allowance from the layerzero (token are sent trought the OTF2 DcntEth implementation) relay to transfer the tokens but the user sending them has no allowance or method to "save" the bridged token :

https://github.com/code-423n4/2024-01-decent/blob/011f62059f3a0b1f3577c8ccd1140f0cf3e7bb29/src/bridge_adapters/DecentBridgeAdapter.sol#L127-L139

The StargateBridgeAdapter#sgReceive has the tokens already transferred in

https://github.com/code-423n4/2024-01-decent/blob/011f62059f3a0b1f3577c8ccd1140f0cf3e7bb29/src/bridge_adapters/StargateBridgeAdapter.sol#L183-L207

In the process of bridging next step is the swapping of tokens part, both contract end using the following swap call inside the UTB#receiveFromBridge :

https://github.com/code-423n4/2024-01-decent/blob/011f62059f3a0b1f3577c8ccd1140f0cf3e7bb29/src/UTB.sol#L311-L318

which choses a swapper and tries to achieve a successful swap

https://github.com/code-423n4/2024-01-decent/blob/011f62059f3a0b1f3577c8ccd1140f0cf3e7bb29/src/UTB.sol#L141 https://github.com/code-423n4/2024-01-decent/blob/011f62059f3a0b1f3577c8ccd1140f0cf3e7bb29/src/UTB.sol#L95

in case of the provided UniSwapper swapper the swapper.swap(swapInstructions.swapPayload); line can revert the call and leave the token inside the two mentioned bridges.

The swap in case of the UniSwapper can fail in one of the two reasons :

in the line

https://github.com/code-423n4/2024-01-decent/blob/011f62059f3a0b1f3577c8ccd1140f0cf3e7bb29/src/swappers/UniSwapper.sol#L138

can fail with the revert Too little received

and in the line

https://github.com/code-423n4/2024-01-decent/blob/011f62059f3a0b1f3577c8ccd1140f0cf3e7bb29/src/swappers/UniSwapper.sol#L159

can fail with the revert Too much requested

If the revert happens the token don't get saved to the refund address.

Tools Used

Manual review

Recommended Mitigation Steps

Account for the possibility that the swap can fail on the destination chain and if it happens transfer funds/tokens to the refund address. Something like :

// for both bridge contract the change is the same
-        IUTB(utb).receiveFromBridge(
-            postBridge,
-            target,
-            paymentOperator,
-            payload,
-            refund
-        );
+try IUTB(utb).receiveFromBridge(
+            postBridge,
+            target,
+            paymentOperator,
+            payload,
+            refund
+        ) {
+        }
+        catch {
+            IERC20(swapParams.tokenIn).transfer(refund, swapParams.amountIn) // the same amount we have successfully transferred in
+        }

Assessed type

Token-Transfer