Kromatika Finance

When `executeCall` from `GaslessForwarder` is used to call `multicall` on `MetaSwapRouter`, and `multicall` then delegates to another function like `swap`, the nested call (`swap`) cannot correctly parse the sender address, leading to potential issues. ### `GaslessForwarder` contract ```solidity function executeCall (){ ... (bool success, bytes memory result) = request.targetAddress.call{ value: msg.value }( abi.encodePacked(request.data, sender) ); ... } ``` The `executeCall` will append the actual sender's address to the end of the `calldata`. ### `MetaSwapRouter` contract: ```solidity function isTrustedForwarder(address forwarder) internal view returns(bool) { return trustedForwarders[forwarder]; } function _msgSender() internal virtual override view returns (address payable ret) { if (msg.data.length >= 24 && isTrustedForwarder(msg.sender)) { // At this point we know that the sender is a trusted forwarder, // so we trust that the last bytes of msg.data are the verified sender address. // extract sender address from the end of msg.data assembly { ret := shr(96,calldataload(sub(calldatasize(),20))) } } else { return msg.sender; } } function multicall(bytes[] calldata data) public payable override returns (bytes[] memory results) { ... for (uint256 i = 0; i < data.length; i++) { (bool success, bytes memory result) = address(this).delegatecall(data[i]); ... } } function swap (...){ ... address payable sender = _msgSender(); ... } ``` When `executeCall` executes `multicall`, and `multicall` in turn executes something like `swap`, the `swap` function expects the sender's address to be at the end of its `calldata`. However, since the sender was appended to the entire `multicall` payload, it won't be where `swap` expects it. This mismatch can lead to reverts or potential exploits, as the `swap` function might interpret incorrect data as the `sender` address. Example Scenario 1. The `executeCall` function sends `calldata` (e.g., `bytes data[1] + sender`) to `multicall`. 2. `multicall` parses only `bytes data[1]` and delegates the call to `swap`, not considering the appended `sender`. 3. During the delegated call to `swap`, `isTrustedForwarder(msg.sender)` remains valid, and swap attempts to parse `sender` from `data[0]`. 4. This can lead to incorrect parsing of the `sender` address, causing reverts or potential exploits.

Calling a user provided address is dangerous, especially in a public function with no access control restriction. An attacker could deploy a malicious contract and use the vulnerable function to trigger a call to the malicious contract, potentially stealing user funds or causing other serious damages. File: GaslessInterfaceMulticall.sol ```solidity=29 function approveToken(address token, uint256 amount, address spender) public { IERC20(token).approve(spender, amount); } ``` Without access control, any address that interacts with the contract can call the `approveToken()` function and approve the spending of tokens from the contract's balance on behalf of any spender. This means that anyone, including potentially malicious actors, can gain control over the tokens held by the contract and transfer them to another address without the contract owner's explicit consent. --- File: GaslessSwapAdapter ```solidity=49 TransferHelper.safeApprove( address(data.tokenFrom), data.aggregator, approvalAmount ); ``` The `adapt()` function has no access control, anyone can this function to gain allowance of specified token from this contract. --- File: SwapAggregatorAdapter.sol ```solidity=40 TransferHelper.safeApprove( address(data.tokenFrom), data.aggregator, data.amountFrom ); ``` The `adapt()` function has no access control, anyone can this function to gain allowance of specified token from this contract. **The issue of `adapt()` function is limited since the `SwapAggregatorAdapter` contract is intended to be delegated called by the `FlashWallet` contract. The `SwapAggregatorAdapter` contract itself does not have any tokens.**

In the `GaslessSwapAdapter` contract, there is an issue when swapping ETH (`fromToken`) for another token (`toToken`). Currently, the amount of ETH to be swapped is calculated based on the balance of the contract (`address(this)`) and the amount of ETH is sent by the user. However, this can result in more ETH being swapped than the user expects. If the user sends additional ETH during the gasless swap, all of it will be used for the token swap, without any possibility of refunding the excess amount. ```solidity=45 if (!LibERC20Adapter.isTokenETH(data.tokenFrom)) { approvalAmount = address(data.tokenFrom) == address(data.paymentToken) ? data.amountFrom.sub(data.paymentFees) : data.amountFrom; TransferHelper.safeApprove( address(data.tokenFrom), data.aggregator, approvalAmount ); } else { senderAmount = address(data.tokenFrom) == address(data.paymentToken) ? address(this).balance.sub(data.paymentFees) : address(this).balance; } ```

In the `TransferAdapter` contract, function `adapt()` performs a token transfer with a cheaper `require` statement placed after the transfer operation. ```solidity=33 uint256 amountToTransfer; if(LibERC20Adapter.isTokenETH(data.token)){ amountToTransfer = address(this).balance.sub(data.feesAmount); payable(address(data.receiver)).transfer(amountToTransfer); payable(data.validator).transfer(data.feesAmount); } else { amountToTransfer = data.amountFrom.sub(data.feesAmount); _transfer(data.token, payable(data.receiver), amountToTransfer); _transfer(data.token, payable(data.validator), data.feesAmount); } require(amountToTransfer > 0, 'AmountToTransfer is zero'); ```

In the `GaslessSwapAdapter` contract, it will pay payment fees to compensate validators after swapping is made. The payment token is either `tokenFrom` or `tokenTo` which is directly transferred from the flash wallet to validator. In the `GaslessSwapAdapter` contract, validators are compensated with payment fees after a swap is completed. The payment token used for compensation can either be `tokenFrom` or `tokenTo`, and it is directly transferred from the flash wallet to the validator. If the `paymentToken` is a regular ERC20 token without a transfer fee, then the `paymentFeesAfter` value is calculated as the sum of `paymentFeesBefore` and `paymentFees`. However, if the `paymentToken` is a deflationary token with a transfer fee, the `paymentFeesAfter` value will be less than the sum of `paymentFeesBefore` and `paymentFees`. It is important to note that the design requires the `paymentToken` to disallow transfer fees and not support deflationary tokens in the swap pair. ```solidity=73 uint256 paymentFeesBefore = LibERC20Adapter.getTokenBalanceOf( IERC20(data.paymentToken), data.validator ); _transfer(data.paymentToken, payable(data.validator), data.paymentFees); uint256 paymentFeesAfter = LibERC20Adapter.getTokenBalanceOf( IERC20(data.paymentToken), data.validator ); require(paymentFeesAfter.sub(data.paymentFees) >= paymentFeesBefore, 'GSA_FNM'); ```

There is an inconsistency of checking `amountToMin` between regular swap and Gasless swap. In the regular swap, the code verifies that the higher value between the amount of `tokenTo` tokens initially swapped and the actual amount received by the recipient satisfies the minimum requirement specified by `data.amountToMin`. ```solidity=64 require(recipientTokenToBalanceAfter >= recipientTokenToBalanceBefore, 'SAA_NEG'); uint256 diffRecipientToken = recipientTokenToBalanceAfter.sub(recipientTokenToBalanceBefore); outputTokenAmount = outputTokenAmount > diffRecipientToken ? outputTokenAmount : diffRecipientToken; require(outputTokenAmount >= data.amountToMin, 'SAA_MIN'); ``` However, in the Gasless swap, the code only verifies that the amount of `tokenTo` tokens transferred to the recipient after deducting the payment fee meets the `data.amountToMin` requirement. ```solidity require(_transfer( data.tokenTo, context.recipient, transferToBalance ) >= data.amountToMin, 'GSA_MIN'); ``` This inconsistency implies that the Gasless swap may not consider the actual amount received by the recipient but rather focuses on the transferred amount after deducting fees. This difference could impact the accuracy of verifying the minimum requirement in the Gasless swap compared to the regular swap.

One or more parameters with `memory` data location are never modified in their functions and those functions are never called internally within the contract. Thus, their data location can be changed to `calldata` to avoid the gas consumption copying from calldata to memory. ```solidity=33 function multicall(Call[] memory calls) public returns (uint256 blockNumber, Result[] memory returnData) { ``` `multicall` has memory location parameters: `calls`.

The contract has a `receive()` function or payable functions, making it able to receive native tokens. However, it does not have a function to withdraw the funds, which can lead to permanently locked tokens within the contract. ```solidity=47 receive() external payable {} ```

The smart contract contains low-level calls such as `.call()` and `.delegatecall()`. Since these calls bypass some of the automatic checks that Solidity provides, like function type checks, they can introduce vulnerabilities, logic errors, or unexpected behavior. ```solidity=25 (success, resultData) = target.delegatecall(callData); ``` The `FlashWallet` smart contract employs a `delegatecall` to interact with an untrusted callee. The `delegatecall` function enables a contract to invoke a function from another contract while maintaining the caller's state. However, it is crucial to note that this approach requires the storage layout of the caller contract to be fully compatible with the callee contract. If the callee contract is untrusted and malicious, it can potentially manipulate the storage of the caller contract in unexpected ways. This poses a significant risk as the caller's storage can be modified in unintended and potentially harmful ways, compromising the integrity and security of the contract's data. --- ```solidity=77 (bool success, bytes memory result) = request.targetAddress.call{ value: msg.value }( abi.encodePacked(request.data, sender) ); ``` --- ```solidity=40 (bool success, bytes memory ret) = target.call{gas: gasLimit}(abi.encodePacked(callData,msg.sender)); ``` --- ```solidity=14 (bool success, bytes memory result) = address(this).delegatecall(data[i]); ```

In the `TransferAdapter` contract, if a user attempts to transfer tokens to themselves in gasless, it could result in a loss of tokens for the user, as the tokens would be transferred and subsequently received back with payment fees deducted, resulting in a net loss due to payment fees. Hence, it is essential to add a check to ensure that the sender and recipient addresses are not the same. ```solidity=26 TransferData memory data = abi.decode(context.data, (TransferData)); require(data.sender != address(0), 'Sender not valid'); require(address(data.token) != address(0), 'Token not valid'); require(data.validator != address(0), 'Validator not set'); ``` Similarly, in the `GaslessSwapAdapter` contract, if a user attempts to swap the same token for itself, it could result in a loss of tokens for the user due to payment fees. Therefore, it is necessary to ensure that `tokenFrom` and `tokenTo` addresses are not the same. Additionally, the contract currently lacks a validation to confirm that the `paymentToken` is either `tokenFrom` or `tokenTo`. As a result, if `paymentToken` is a different token altogether, no payment fees will be charged. ```solidity=39 GaslessSwapData memory data = abi.decode(context.data, (GaslessSwapData)); ```