CrossChainRelayerArbitrum contract: GasLimitTooHigh revert error not caught

Lines of code Vulnerability details Summary The relayCalls function in the CrossChainRelayerArbitrum contract reverts when the gasLimit parameter is greater than the maxGasLimit, but it does not have a catch block to handle the error. As a result, the transaction will fail without providing any...

CrossChainRelayerArbitrum contract gas limit bug

Lines of code Vulnerability details Summary The CrossChainRelayerArbitrum contract uses the maxSubmissionCost parameter to determine if the gasLimit provided to the processCalls function is greater than the maxGasLimit. This is incorrect because maxSubmissionCost should not be used to determine t...

ProcessedCalls event missing transaction hash

Lines of code Vulnerability details Summary The CrossChainRelayerArbitrum contract is missing the txHash parameter in the ProcessedCalls event. Impact The txHash is used to identify the transaction that was processed. Without this parameter, it will be impossible to know which transaction was...

Incorrect use of AddressAliasHelper.applyL1ToL2Alias() in _isAuthorized()

Lines of code Vulnerability details Summary In the isAuthorized function, the require statement checks if the msg.sender is equal to the result of calling AddressAliasHelper.applyL1ToL2Alias with relayer as the argument. However, this is incorrect, as AddressAliasHelper.applyL1ToL2Alias is intend...

setRelayer function not checking for null relayer address

Lines of code Vulnerability details Summary When calling the setRelayer function with a null relayer address, the function does not check for this and allows the address to be set. This issue can cause the contract to fail when calling the executeCalls function and potentially cause loss of funds...

Upgraded Q -> M from #400 [1670236164031]

Judge has assessed an item in Issue 400 as M risk. The relevant finding follows: L04 - LiquidStakingManager.dao can rug node operators with executeAsSmartWallet daoCommissionPercentage is used to calculate the portion of node operator network rewards that are sent to dao, when a node runner is...

Upgraded Q -> M from #38 [1670234424045]

Judge has assessed an item in Issue 38 as M risk. The relevant finding follows: L2. Pool selection for the compound is not restricted Compound function of AutoPxGmx contract is public and available for everyone. An attacker can create a custom pool with a higher fee value currently, on tests it...

Upgraded Q -> M from #400 [1670236078897]

Judge has assessed an item in Issue 400 as M risk. The relevant finding follows: L03 - LiquidStakingManager.dao can rug node operators with executeAsSmartWallet 202: function executeAsSmartWallet 203: address nodeRunner, 204: address to, 205: bytes calldata data, 206: uint256 value 207: external...

Upgraded Q -> M from #316 [1670230229509]

Judge has assessed an item in Issue 316 as M risk. The relevant finding follows: compound in AutoPxGmx can be called by anyone and can be sandwiched if a poorly chosen amountOutMinimum is used. The idea is to call the function often by adding an incentive to the caller. There is a problematic...

Incorrect _isAuthorized function logic

Lines of code Vulnerability details Summary The isAuthorized function in the CrossChainExecutorOptimism contract compares the message sender address to the address of the crossDomainMessenger contract, but it should be comparing the xDomainMessageSender value returned by the crossDomainMessenger...

Missing msg.value when executing the cross-chain request

Lines of code Vulnerability details Impact the cross-chain request will not support smart contract that requires ETH payment in destination chain on execution side. Proof of Concept When a user relayers call and performs a cross-chain request, the executor needs to execute the request in the...

Funds may be lost if processCalls is called from a contract

Lines of code Vulnerability details Impact In CrossChainRelayerArbitrum.processCalls, msg.sender is set as the address to receive any refund both excess fee refund and call value refund in the createRetryableTicket call. Arbitrium credits the refunded value to L2 balance, so if the user doesn't...

the executor can execute fake cross-chain function call

Lines of code Vulnerability details Impact The caller on relayer side can be rugged if the executor call the executeCall on execution side directly to use consume the nonce and fake cross-chain function call. Proof of Concept The expected behavior is that: the relayer relays a cross-chain request...

Relayer/executor-already-set Error in CrossChainRelayerArbitrum Contract

Lines of code Vulnerability details Summary The setExecutor function in the CrossChainRelayerArbitrum contract improperly reverts when the executor variable has already been set. Impact This bug could prevent the CrossChainRelayerArbitrum contract from properly setting the executor variable,...

Integer Overflow

Lines of code Vulnerability details Impact Potential integer overflow vulnerability in the relayCalls function. The function does not check for the maximum value of the gasLimit parameter, and if it is set to a value greater than the maxGasLimit, it will cause an integer overflow. Integer overflo...

Upgraded Q -> M from #402 [1670185822442]

Judge has assessed an item in Issue 402 as M risk. The relevant finding follows: Staked Gmx RewardTracker may retain allowances Summary: Both the configureGmxState function and the setContractContracts c, address contractAddress can be used to update the PirexGmx contract's stakedGmx storage...

DoS on relayCalls when the nonce variable reach type(uint256).max

Lines of code Vulnerability details Impact Denial of service on relayCalls functions when the nonce variable reach typeuint256.max Proof of Concept When the smart contracts start to be used, the variable in storage nonce will start to increment by 1, and since the nonce variable cannot be...

Fail to verify the result of a low level function call

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. It fails to check properly if the call is successful because: 1 It does not check the return data; 2 it does not check if the target address is a valid contract. A contract that has no code will still...

Potential reentrancy attack

Lines of code Vulnerability details Impact There is a potential of reentrancy attack in executeCalls in EthereumToArbitrumExecutor.sol since CallLib is making an external call with its executeCalls and we do not know the implementation of the contract that will be called eventually. The same issu...

Upgraded Q -> M from #373 [1670018401792]

Judge has assessed an item in Issue 373 as M risk. The relevant finding follows: N2. ETH not accumulated in previewAccumulatedETH supposed to have accumulated += ... Although it is an external view function, depending on its usages, it may present more issues to the callers. --- The text was...

[ZZ-001] PARENT_CANNOT_CONTROL and CANNOT_CREATE_SUBDOMAIN fuses can be bypassed

Severity: High Status: Has been reported to and comfirmed by Jeff ENS team Report Time: 11/28/2022 12:31 AM EST Description The fuse constraints can be violated by a malicious owner of the parent node i.e., the hacker. There are two specific consequences the hacker can cause. Suppose the subnode...

Relayed calls in EthereumToArbitrumRelayer can be replayed

Lines of code Vulnerability details Impact A relayed call can be processed multiple times allowing somebody to execute the user's call multiple times. The bridge allows arbitrary calls to contracts. Depending on the nature of the call, this could result in a loss of funds for the user. Proof of...

Reentranxcy in executeCalls()

Lines of code Vulnerability details Impact The contract first checks that the message sender is authorized and then marks the provided nonce as executed before calling the executeCalls function in CallLib. However, if CallLib.executeCalls calls back into this contract, the executeCalls function...

Upgraded Q -> M from #265 [1669939411439]

Judge has assessed an item in Issue 265 as M risk. The relevant finding follows: ETH not updated in internal accounting of giant pools Giant pools have a feature of bringing ETH back to the giant pools from the vaults. The received ETH in not updated in internal accounting and therefore cannot be...

[ZZ-004] During the deprecation period where both .eth registrar controllers are active, a crafted hack can be launched and cause the same malicious consequences of [ZZ-001] even if [ZZ-001] is properly fixed

Severity: High Status: Has not been reported Description, Specifically, according to the documentation, there will be a deprecation period that two types of .eth registrar controllers are active. Names can be registered as normal using the current .eth registrar controller. However, the new .eth...

Upgraded Q -> M from #236 [1669938261828]

Judge has assessed an item in Issue 236 as M risk. The relevant finding follows: It is possible the DAO determine the amount of commission very high for its own benefit, so setting a range for determining the commission seems logical. Especially MAX commission should be pre- defined. --- The text...

Upgraded Q -> M from #205 [1669936745167]

Judge has assessed an item in Issue 205 as M risk. The relevant finding follows: L01 - No check if EOARepresentative or EOARepresentativeOfNodeRunner is an EOA or a smart contract Impact A smart contract can end up being assigned as a smartWalletRepresentative. Such smart contract might not have...

Upgraded Q -> M from #121 [1669815281189]

Judge has assessed an item in Issue 121 as M risk. The relevant finding follows: Require - always false contracts/liquid-staking/LiquidStakingManager.sol:280 isNodeRunnerWhitelistednodeRunner comparing to itself requireisNodeRunnerWhitelistednodeRunner != isNodeRunnerWhitelistednodeRunner,...

Upgraded Q -> M from #16 [1669734774225]

Judge has assessed an item in Issue 16 as M risk. The relevant finding follows: AQ6: This function provides too much power to Dao, if the dao calls the function, then he can be the node runner of each smart wallet and then call withdrawETHForKnot to drain each smart wallet. --- The text was updat...

Upgraded Q -> M from #38 [1669737057849]

Judge has assessed an item in Issue 38 as M risk. The relevant finding follows: 6. require check will always be false!! the require check will always be false so it the function will not do what it was designed to do and it will always revert Unnecessary update to same status...

tokenID that is not minted will be stored into the feeRecipient storage

Lines of code Vulnerability details Impact In the original code, tokenID is incremented just after mint function is executed. Afterwards, tokenID is stored into the feeRecipient storage. As a result, tokenID that is not minted will be stored into the feeRecipient storage. Proof of Concept In the...

First depositor can inflate share price

Lines of code Vulnerability details Impact A well-known vulnerability for ERC4626 vaults is the inflation of the share price on the first deposit. Because AutoPxGlp and AutoPxGmx use the balance of the underlying asset for totalAssets and do not have an initial minimum deposit amount, they are al...

The First Turnile Mint Token ID starts with 0.

Lines of code Vulnerability details Impact The First Turnile Mint Token ID starts with 0. Proof of Concept After deployment, the first Turnile token ID to be minted when a user calls the register function, is 0. At this point, the currentTokenId becomes 1 but the token doesn’t exist until the...

lack of unregiestered function existen

Lines of code Vulnerability details there is no function to let a smart contract to unregester from a tokenid , since a smart contract can only be regestered once its highly recommended to give it an ability to unregister from a tokenid and register again bob calls register bob has two...

Register and assign functions need more validation due to phishing vectors.

Lines of code Vulnerability details Impact The Turnstile contract is open for phishing. Since the interaction between the contracts is in atomic construction and the calls can't be controlled at low levels, it might open ways to phishing the contracts. Let's assume that there is a contract that i...

AutoPxGlp and AutoPxGmx are not compliant with ERC4626 standard

Lines of code Vulnerability details Proof of Concept In both contracts, the previewWithdraw function has the same body // Calculate shares based on the specified assets' proportion of the pool uint256 shares = convertToSharesassets; // Save 1 SLOAD uint256 totalSupply = totalSupply; // Factor in...

fee distribution is only for the msg.to contract, instead of the to address of the call traces, which is not reasonable for the gas economic system.

Lines of code Vulnerability details Impact The target contract of the fee distribution is got by contract := msg.To in the evmhooks.go . So the fee distribution is only for the msg.to contract, instead of the to address of the call traces. It means that any one use a contract wallet or setup a...

Compounding is vulnerable to sandwich attack

Lines of code Vulnerability details Impact Function compound is called in every deposit/withdraw in AutoPxGmx contract. It claim rewards in form of gmxBaseReward and swap them to gmx token. They used amountOutMinimum from input params gmxAmountOut = SWAPROUTER.exactInputSingle...

Fuses rollover with renew

Lines of code Vulnerability details Impact User will not be able to change fuses even after actual expiry Proof of Concept 1. User A wraps his .eth domain test.eth using the wrapETH2LD function with fuse CANNOTBURNFUSES 2. This internally calls wrapETH2LD function with User A provided fuses 3. Th...

NameWrapper: expired names behave unwrapped

Lines of code Vulnerability details Impact expired Names are supposed to be unregistered, but it behaves like unwrapped parent with CANNOTCREATESUBDOMAIN fuse can "create" again an expired name parent can ENS.setSubdomainOwner before burning CANNOTCREATESUBDOMAIN to be able to use the subdomain...

NameWrapper: one can renew to DoS a Name

Lines of code Vulnerability details Impact Anyone with enough eth can make a name impossible to be used anymore Proof of Concept Below is a snippet of the proof of concept. The whole code can be found in this gist. And how to run test is in the comment in the gist. This proof of concept...

The recipient address check during handling register events will confuse users and block the users contracts registering

Lines of code Vulnerability details Impact The check about if the receiver account exists in the evm store doesn't make sense and will cause users to encounter a confusing exception. And the RegisterEvent function will not throw an exception to revert the tx, the source contract will be wrote in...

A registered contract won't earn fees if _recipient is a fresh address

Lines of code Vulnerability details Impact Users might fall victims of a false positive: if they use a fresh account as an NFT recipient during contract registration, the transaction won't revert, but the registered contract will never earn fees for the token holder. And since a contract can be...

Ownership NFT Can be Minted by Anyone

Lines of code Vulnerability details Impact In Turnstile.sol, register is a public function callable by anyone. Any msg.sender calling this function the first time is going to bypass the modifier onlyUnregistered. As long as a non-zero recipient has been inputted, a new NFT is going to be minted t...

MINTING OF NFT AT WILL

Lines of code Vulnerability details Impact register is an unrestricted public function where any new msg.sender is going to get through the modifier onlyUnregistered. With a non-zero recipient argument passed into the function, a new NFT is going to be minted to the recipient. Consequently, an...

Uniswap V3 swaps are vulnerable to a sandwich attack

Lines of code Vulnerability details Impact As the amountOutMinimum is always hardcoded with 1 in the AutoPxGmx, then the Uniswap V3 swap is vulnerable to a frontrun / sandwich attack. Proof of Concept Even though the amountOutMinimum may never be 0 because it is prevented against it: if...

There is no re-register o re-assign function

Lines of code Vulnerability details Impact There is no re-register or re-assign option for the smart contracts. Let's assume a smart contract is registered either through the register function with a new NFT minted or the assign function to an existing NFT. However, if somehow, the NFT is burned ...

CallEVM does not validate the existence of the address being called

Lines of code Vulnerability details Impact Evm.go's CallEVM function performs a EVM call to a given address with an input amount. However, the existence of the address is not validated. If the call is made with an amount to a contract, where it might be deleted or non-existed, the funds will be...

isContract might return false for the contracts

Lines of code Vulnerability details Impact The Turnstile contract's register function assumes the msg.sender is a smart contract. The validation of this is carried out in eventhandler.go's ValidateContract function. ValidateContract checks whether the address has an emptyCodeHash which is zero...

The existence of the tokenID is not validated in distributeFees()

Lines of code Vulnerability details Impact Turnstile contract has distributeFees function which the Canto team/smart contract utilizes to distribute the fees to the tokenID's for the smart contract that is registered through register function. The existence of the tokenID's are checked both in...