GiantMevAndFeesPool::afterTokenTransfer doesn't update claimed amount of sender

Lines of code Vulnerability details Impact After a token transfer of GiantMevAndFeesPool's GiantLP, the receiver gets their claimed amount updated to the correct value, but the sender does not. If more than zero tokens were transferred, that amount in the sender's future rewards will be lost, and...

batchRotateLPTokens in GiantSavETHVaultPool can be used to steal LPTokens

Lines of code Vulnerability details Impact real LPTokens can be transferred out of GiantSavETHVaultPool through fake stakingFundsVaults provided by an attacker. Proof of Concept batchRotateLPTokens takes in stakingFundsVaults, oldLPTokens, newLPTokens and rotate amounts from old to new tokens. Th...

ERC20 return values not checked

Lines of code Vulnerability details Impact 'token' is a ERC20 from LPToken.sol The ERC20.transfer and ERC20.transferFrom functions return a boolean value indicating success. This parameter needs to be checked for success. Some tokens do not revert if the transfer failed but return false instead...

Med: withdrawDETH is not functional for array lengths greater than one.

Lines of code Vulnerability details Description The withdrawDETH function is used in GiantSavETHVaultPool to burn user's LP tokens and grant them dETH. It loops over all input vaults and all input LPTokens, and for each one calls lpTokenETH.burnmsg.sender, amount; Before that, it uses...

Medium: Users receive an incorrect account of their accumulated ETH in GiantMevAndFeesPool.

Lines of code Vulnerability details Description GiantMEVAndFeesPool exposes previewAccumulatedETH for users to view how much ETH they have accumulated through the vault: function previewAccumulatedETH address user, address calldata stakingFundsVaults, LPToken calldata lpTokens external view retur...

Single-step process for critical ownership transfer/renounce is risky

Lines of code Vulnerability details Single-step process for critical ownership transfer/renounce is risky Impact The following contracts and functions, allow owners to interact with core functions such as: execute, rawExecute and setApproval in OwnableSmartWallet registerKnotsToSyndicate,...

bringUnusedETHBackIntoGiantPool in GiantSavETHVaultPool can be used to steal LPTokens

Lines of code Vulnerability details Impact real LPTokens can be transferred out of GiantSavETHVaultPool through fake savETHVaults provided by an attacker. Proof of Concept bringUnusedETHBackIntoGiantPool takes in savETHVaults, lpTokens, and burns certain amount olpTokens. The tokens are thoroughl...

Possibly reentrancy attacks in _distributeETHRewardsToUserForToken function

Lines of code Vulnerability details Author: rotcivegaf Impact The root of the problem are in the distributeETHRewardsToUserForToken who makes a call to distribute the ether rewards. With this call the recipient can execute an reentrancy attack calling several times the different function to steal...

Users can block other users from redeeming their ETH in Vaults

Lines of code Vulnerability details The burnLPToken of a protected vault allow users to burn LP tokens in exchange of ETH or dETH. In the case of ETH, ie when the BLS key has not had its derivatives minted yet, the function checks the liquidity is not fresh by checking...

QA Report

See the markdown file with the details of this report here. --- The text was updated successfully, but these errors were encountered: All reactions...

dETH are branded as slash proof, but ETH2 slashing could make 32 deposit drop much below 24 (down to 0), making dETH undercollateralized

Lines of code Vulnerability details Description dETH is advertised as fault proof , slash proof ETH However, ETH2 staked deposit can be slashed from 32 down to 0, not just to 24 as would be expected24 dETH printed. This means dETH is undercollateralized, and indeeds bears the risk of being "paper...

Upgraded Q -> M from #164 [1668687728737]

Judge has assessed an item in Issue 164 as M risk. The relevant finding follows: 01 Lack of check if dust ether transfer is successful --- The text was updated successfully, but these errors were encountered: All reactions...

Upgraded Q -> M from #209 [1668684399391]

Judge has assessed an item in Issue 209 as M risk. The relevant finding follows: SINGLE POINT OF FAILURE --- The text was updated successfully, but these errors were encountered: All reactions...

Upgraded Q -> M from #74 [1668688523897]

Judge has assessed an item in Issue 74 as M risk. The relevant finding follows: Low-7 EXCHANGE & SWAP are able to transfer any user funds to other addresses --- The text was updated successfully, but these errors were encountered: All reactions...

Broken Upgradable Logic in Pool.sol

Lines of code Vulnerability details Impact The Pool smart contract allows a user to predeposit ETH so that it can be used when a seller takes their bid. It uses an ERC1967 proxy pattern and only the exchange contract is permitted to make transfers. The smart contract inherits the...

RETURN STATEMENT OF THE transferFrom FUNCTION ALWAYS RETURN TRUE EVEN THE TRANSFER IS FAILED . IF RETURN TRUE FOR ALL TRANSACTIONS IT WILL CAUSE A PROBLEM AND LOSE OF AMOUNT

Lines of code Vulnerability details Impact When ever we calling transfer from function it will return true even the transfer failed. So as per function we think the transfer is success. But in real that transfer may or may not be failed. We don't get the exact status of the transfer Proof of...

Trader can still execute the order even after cancelling the order

Lines of code Vulnerability details Impact There are no checks to verify whether the order has been cancelled or not in execute function. This will enable traders to place the order even after cancellation Proof of Concept Execute cancelOrder function with Order data Include the Order in input of...

Upgraded Q -> M from #381 [1668467789168]

Judge has assessed an item in Issue 381 as M risk. The relevant finding follows: There is no limit for FlashLoanFee function setFlashLoanFeeuint256 flashLoanFee external override onlyOwner uint256 oldFlashLoanFee = flashLoanFee; if oldFlashLoanFee == flashLoanFee revert...

Upgraded Q -> M from #323 [1668467355303]

Judge has assessed an item in Issue 323 as M risk. The relevant finding follows: L00: beforeTokenTransfer function called with wrong params in LBToken Line 237 seems to be a copy pasta mistake from line 209 in LBToken.sol. On line 237 when burning tokens, to should be zero, and amount of from's...

The function _execute could be called externally

Lines of code Vulnerability details Author: rotcivegaf Impact The execute use a modifier to only can called internally, also specified in the documentation of the function: Must be called internally. But this modifier can be pass if a contract call the execute or bulkExecute and in the returnDust...

User's assets can be drained without payment due to invalid signature check

Lines of code Vulnerability details Impact Exchange::execute uses validateSignatures function to verify if an order is signed by both parties. However, this function does not verify the signature when order.trader == msg.sender. Hence, malicious actor can prepare a bundle of all seller's Orders...

Unintended code path execution by modifying user controlled input

Lines of code Vulnerability details Impact Unintended code path execution by modifying user controlled input. The deal maker gets to pick if buyer or seller matching policy are executed. The actual impact of this vulnerability would depend on the matching policy. Any where from wasted gas to loss...

Upgraded Q -> M from #348 [1668468155840]

Judge has assessed an item in Issue 348 as M risk. The relevant finding follows: L01 Wrong parameter order inside beforeTokenTransfer in LBtoken::burn call should be beforeTokenTransferaccount, address0, id, amount; --- The text was updated successfully, but these errors were encountered: All...

Upgraded Q -> M from #205 [1668464751854]

Judge has assessed an item in Issue 205 as M risk. The relevant finding follows: 108 --- The text was updated successfully, but these errors were encountered: All reactions...

Exchange.sol has payable functions but no way of withdrawing

Lines of code Vulnerability details Exchange.sol has payable functions but no way of withdrawing Impact Functions are payable: IExchange.execute Exchange.execute Exchange.bulkExecute Exchange.execute UUPSUpgradeable.upgradeToAndCall But there is no way of withdrawing, so funds can be lost PoC But...

Reentrancy attack on fee transferring

Lines of code Vulnerability details Vulnerability details Description There is execute function in the Exchange smart contract. The function matches two orders, ensuring the validity of the match, transfers the order fees, etc. When transferring fees, the contract just makes a call to the...

Exchange refund operation will return all ETH stored in the contract instead of the remaining amount from the exchange operation

Lines of code Vulnerability details Exchange refund operation will return all ETH stored in the contract instead of the remaining amount from the exchange operation The function that refunds remaining ETH in the Exchange contract will send back all the balance present in the contract instead of...

User funds(ETHs) sent along with bulkExecute tx may be stolen by a reentry attack

Lines of code Vulnerability details Impact The funds ETH that users sent along with the bulkExecute may be stolen. Proof of Concept When a buyer send a bulkExecute tx with msg.value 0 with order of buying token with eth, the sent ETH may be stolen if the tx contains a malicious selling order whic...

Direct theft of buyers ETH funds.

Lines of code Vulnerability details Impact Most severe issue: A Seller or Fee recipient can steal ETH funds from the buyer when he is making a single or bulk execution. Direct theft of funds. Additional impacts that can be caused by these bugs: 1. Seller or Fee recipient can cause next in line...

EVERY TIME ONCE _execute FUNCTION COMPLETED NEED TO SET isOpen TO 0. OTHERWISE WE CAN CALL EXECUTE FUNCTIONS MULTIMPLE TIMES.

Lines of code Vulnerability details Impact IN THIS WAY WE CAN CALL AND EXECUTE FUNCTIONS MULTIPLE TIMES . EVERY TIME BEFORE CALL EXECUTE NEED TO CALL INITIALIZE FUNCTIONS. Proof of Concept function executeInput calldata sell, Input calldata buy public payable reentrancyGuard internalCall...

Exchange owner can consume all orders at arbitrary price

Lines of code Vulnerability details Impact The choice of policy to use for a transaction is determined by the listingTime. The listingTime can be supplied by the caller of execute/bulkExecute and can be arbitrary as along as it passes validation. And the policy of a given order is used to determi...

Counterparty-exchange owner may alter policy manager in execution callback, altering the price of subsequent order matching

Lines of code Vulnerability details Impact In the context of bulkExecute, with a sqeuence of executions requested, transferring ETH, ERC721 or ERC1155 may result in a hook/callback to a counterparty on receipt of ETH or one of these tokens. If this counterparty is also the exchange owner, or is...

Exchange's _returnDust() does not validate return value of call() to send excess ETH to sender.

Lines of code Vulnerability details Impact When a caller to Exchange's execute or bulkExecute includes more ETH than is required to complete the transactions, returnDust is intended to return this excess back to the caller. However, returnDust does not validate that the call it performs to return...

unconventional reentrant structure can result in reentrance into _returnDust

Lines of code Vulnerability details Impact unconventional nonreentrant code structure allows for reentrance from returnDust Proof of Concept Once execute finishes execution, the reentrancy guard is reset to be not in effect, and the flow goes into returnDust. Now caller's receive function can cal...

Pool is not initialized correctly

Lines of code Vulnerability details Impact Pool has no owner and will be un-upgradeable. Proof of Concept Pool does not provide an initialize interface to initialize the owner, so the owner will never be set. Pool as a UUPSUpgradeable can not be upgraded without a valid owner. Tools Used n/a...

Tx should revert when the call in _returnDust failed

Lines of code Vulnerability details Impact User may lose remaining ETH of the transaction Proof of Concept As the returned status of the call in returnDust is ignored, the tx will success even if the call failed, which means the caller does not get his ETH back. Tools Used n/a Recommended...

_returnDust does not revert ether transfer failure

Lines of code Vulnerability details Impact In function returnDust the return value of call is not checked for success. If a user had sent excess ether or if an order in a bulk order had failed, and if the call fails ether will remain in the contract. Users who execute orders later will be able to...

[H-01] owner not set in Pool.sol

Lines of code Vulnerability details The pool.sol contract here is an UUPSUpgradeable contract. But there is no initialize function where Ownableinit is called , due to which owner is 0x0. It would be impossible to call authorizeUpgrade or change ownership of the contract. POC Adding the following...

Admin can drain user funds from the Pool or buy assets for free

Lines of code Vulnerability details Impact We assume that the admin is honest, however there is still possibility of exploiting asset policy contract to and set price to 0 in oder to buy an asset for free - or even worse - drain user funds by setting the price really high in...

On _returnDust, call opcode's return value not checked

Lines of code Vulnerability details Impact The call opcode's return value not checked, which could leads to the originator lose funds. Proof of Concept The caller of Exchange.sol::execute or Exchange.sol::bulkExecute could be a contract who may not implement the fallback or receive function, when...

Pool designed to be upgradeable but does not set owner, making it unupgradeable

Lines of code Vulnerability details Description The docs state: "The pool allows user to predeposit ETH so that it can be used when a seller takes their bid. It uses an ERC1967 proxy pattern and only the exchange contract is permitted to make transfers." Pool is designed as an ERC1967 upgradeable...

Upgraded Q -> M from #70 [1668468349340]

Judge has assessed an item in Issue 70 as M risk. The relevant finding follows: Flash loan fee can be set to 100% Contract: Issue: In setFlashLoanFee function, If Admin has set flashloan fee to 100% then user taking X amount as flashloan has to pay a fee equal to X which does not make sense...

Upgraded Q -> M from #446 [1668468223347]

Judge has assessed an item in Issue 446 as M risk. The relevant finding follows: L-01 There should be an upper limit for LBFactory.flashLoanFee If the admin sets the flashLoanFee too high, the flash loan functionality might be useless as users won't use it. --- The text was updated successfully,...

Upgraded Q -> M from #336 [1668467652322]

Judge has assessed an item in Issue 336 as M risk. The relevant finding follows: L-1: Volatility accumulator can be be prevented from decaying by way of dust transactions There is no required minimum swap amount for updating the volatility accumulated. The fp.time is always updated during a swap...

Upgraded Q -> M from #474 [1668467584757]

Judge has assessed an item in Issue 474 as M risk. The relevant finding follows: L-01 Flashloan fee is not validated flashLoanFee is determined at LBFactory's constructor as; constructoraddress feeRecipient, uint256 flashLoanFee setFeeRecipientfeeRecipient; flashLoanFee = flashLoanFee; emit...

Upgraded Q -> M from #334 [1668467418003]

Judge has assessed an item in Issue 334 as M risk. The relevant finding follows: 2. Rug vectors by the owner A malicious owner can call setLBPairImplementation, setFeeRecipient, setFlashLoanFee , setFeesParameters and forceDecay to advantage himself at expenses of the users...

Upgraded Q -> M from #75 [1668466949988]

Judge has assessed an item in Issue 75 as M risk. The relevant finding follows: Line 237, beforeTokenTransferaddress0, account, id, amount; should be beforeTokenTransferaccount, address0, id, amount; --- The text was updated successfully, but these errors were encountered: All reactions...

Upgraded Q -> M from #449 [1668465467675]

Judge has assessed an item in Issue 449 as M risk. The relevant finding follows: FlashLoanFee should be bounded | Low | 1 --- The text was updated successfully, but these errors were encountered: All reactions...

Upgraded Q -> M from #449 [1668465456097]

Judge has assessed an item in Issue 449 as M risk. The relevant finding follows: Error when calling beforeTokenTransfer in the LBToken burn function | Low | 1 --- The text was updated successfully, but these errors were encountered: All reactions...

Upgraded Q -> M from #493 [1668465137655]

Judge has assessed an item in Issue 493 as M risk. The relevant finding follows: 108 --- The text was updated successfully, but these errors were encountered: All reactions...