From 0f0f0e970e942dd7b3970e0d26817e0d45695c2e Mon Sep 17 00:00:00 2001 From: thebrittfactor <135237830+thebrittfactor@users.noreply.github.com> Date: Mon, 4 Nov 2024 16:15:54 -0500 Subject: [PATCH] validate hms --- 2024-10-superposition-hm.csv | 45 ++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 2024-10-superposition-hm.csv diff --git a/2024-10-superposition-hm.csv b/2024-10-superposition-hm.csv new file mode 100644 index 0000000..7976f2c --- /dev/null +++ b/2024-10-superposition-hm.csv @@ -0,0 +1,45 @@ +issue,title,primary finding,validator comment,status,root cause (URL),size,robotLabel +validation-42,Users can't withdraw the full liquidity from their position,,I do not see a security concern here besides some UX problems that can be solved with a periphery contract as it is done in Uniswap.,Unsatisfactory,,44,:robot:_primary +validation-44,Ineffective compilation flag in production can result in missing modules,,Seems QA. Does not explain how can this impact the protocol besided a redeployment.,Unsatisfactory,,44,:robot:_primary +validation-45,Adding delta liquidity with 2^127 results in panic,,Low quality report. There is no impact described in the context of the application. A proof of concept of the impact to the protocol can be requested to the warden.,Unsatisfactory,,140,:robot:_primary +validation-5,Front-Running Vulnerability in Swap Function,,Price limit can act as slippage protection. Moreover there is the swap_2_exact function which should be used in case a min_out want to be specified.,Unsatisfactory,,36,:robot:_primary +validation-18,"SeawaterAMM Smart Contract Audit: Access Control, Delegatecall Risks Vulnerabilities",,Spam,Unsatisfactory,,417,:robot:_primary +validation-21,It's still not possible to set pool's protocol fees ,,This can be invoked via the fallback function in the Solidity contract.,Unsatisfactory,,32,:robot:_primary +validation-22,Non-Constant Time Execution (Timing Attack) could expose data leakage in cryptographic or secure contexts.,,Spam,Unsatisfactory,,36,:robot:_primary +validation-24,Shift overflow risk may cause unexpected results or runtime panics,,Spam,Unsatisfactory,,31,:robot:_primary +validation-25,"Test coverage & edge cases might allow subtle bugs or performance issues to go undetected, leading to unexpected failures in production",,Spam,Unsatisfactory,,37,:robot:_06_group +validation-26,"Overflow in Multiplication (mul_mod and _mul_div) can produce inaccurate results, potentially disrupting calculations critical to financial or cryptographic operations, where precision is paramount.",,Spam,Unsatisfactory,,34,:robot:_05_group +validation-27,"Unsafe Code Usage (In mul_mod and _mul_div) could lead to critical vulnerabilities such as: crashes, data corruption, or security issues in scenarios where memory safety is compromised.",,Spam,Unsatisfactory,,32,:robot:_primary +validation-28,Lack of Precision Handling can lead to rounding errors,,Spam,Unsatisfactory,,31,:robot:_00_group +validation-29,Error Handling in Division by Zero can lead to system crash,,Spam,Unsatisfactory,,30,:robot:_primary +validation-3,Unbounded Number of Positions ,,There is no evidence provided by warden on why is this an issue. What is the difference with for example the unbounded amount of balances that can be created in an ERC20 EVM contract?. ,Unsatisfactory,,38,:robot:_primary +validation-30,Limited test coverage can result in undetected bugs and unhandled scenario,,Spam,Unsatisfactory,,28,:robot:_06_group +validation-31,"Potential Integer Overflow/Underflow Risks which can lead to incorrect liquidity calculations, financial losses or unexpected behavior in smart contracts",,Spam,Unsatisfactory,,24,:robot:_05_group +validation-32,Inconsistent Error Handling can lead to mishandling of liquidity adjustments in the system.,,Spam,Unsatisfactory,,25,:robot:_primary +validation-33,No Test for Edge Cases can lead to operational failures when the code is deployed. ,,Spam,Unsatisfactory,,24,:robot:_primary +validation-34,"Overflow and Underflow Issues can result in incorrect results, allowing users to exploit the system to their advantage ",,Spam,Unsatisfactory,,26,:robot:_05_group +validation-35,"Unchecked arithmetic vulnerability could lead to incorrect price movements, liquidity miscalculations, or drained liquidity pools",,Spam,Unsatisfactory,,29,:robot:_primary +validation-36,"Unsafe Casting Vulnerability can result in lost precision or negative values, which might cause the function to misbehave.",,Spam,Unsatisfactory,,26,:robot:_primary +validation-37,"Improper Error Handling with unwrap() Usage could halt the execution of a transaction, leaving the system in an inconsistent state or exposing it to DoS.",,Spam,Unsatisfactory,,27,:robot:_primary +validation-4,Unchecked Permit Deadline in take_permit2 Function,,The deadline validation is responsability of the permit2 contract,Unsatisfactory,,29,:robot:_primary +validation-9,Users can manipulate fees by exploiting unchecked or improperly validated fee_pips input,,GPT,Unsatisfactory,,38,:robot:_primary +validation-41,No slippage control when withdrawing a position leads to loss of funds,validation-41,"A periphery contract can be used for taking into consideration slippage protection. However, as this involves loss of funds I am marking it as valid in contrast with validation-42",Satisfactory,https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/seawater/src/lib.rs#L749,22,:robot:_03_group +validation-11, Incorrect Return Value in mul_mod Function,validation-11,`ruint::algorithms::div` saves the remainder in the modulus variable so this is not an issue. Reference for more details here: https://docs.rs/ruint/latest/src/ruint/algorithms/div/mod.rs.html#35 I will leave it as satisfactory for better confirmation,Satisfactory,https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/seawater/src/maths/full_math.rs#L28,42,:robot:_primary +validation-13,`createPoolD650E2D0` will not work due to mismatch in solidity and stylus function definitions,validation-13,Inconsistent function signatures in Rust and Solidity contracts,Satisfactory,"https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/sol/SeawaterAMM.sol#L160-L168,https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/seawater/src/lib.rs#L802",69,:robot:_primary +validation-17,Users are incorrectly refunded when liqudity is insufficient,validation-17,Incorrect refund during swaps,Satisfactory,https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/seawater/src/lib.rs#L287-L297,57,:robot:_primary +validation-2,Incorrect token-in transfer amount in swap_2_internal_erc20,validation-17,Incorrect refund during swaps,Satisfactory,https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/seawater/src/lib.rs#L287-L297,53,:robot:_02_group +validation-20,Users can add liquidity to disabled pools,validation-20,Users can add liqudity even if pool is not enabled,Satisfactory,https://github.com/code-423n4/2024-10-superposition/blob/main/pkg/seawater/src/pool.rs#L86,42,:robot:_primary +validation-40,`getApproved` wrongly checks the approved address instead of the owner,validation-40,Reverting if getApproved[tokenId] is the zero address is incorrect,Satisfactory,https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/sol/OwnershipNFTs.sol#L59,37,:robot:_primary +validation-43,Protocol is wrongly refunding too many funds in a swap,validation-17,Incorrect refund during swaps,Satisfactory,https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/seawater/src/lib.rs#L287-L297,60,:robot:_02_group +validation-8,`fee growth outside` set incorrectly when updating a position,,This seems consistent with UniswapV3 implementation: https://github.com/Uniswap/v3-core/blob/d8b1c635c275d2a9450bd6a78f3fa2484fef73eb/contracts/libraries/Tick.sol#L134 . Warden fails to demonstrate a tangible impact,Unsatisfactory,,39,:robot:_primary +validation-19,Pool initialisation lacking checks,,No security impact to the protocol or to the users described,Unsatisfactory,,45,:robot:_primary +validation-39,Missing check on the transfer_position_E_E_C7_A3_C_D function in lib,,No security impact to the protocol or to the users described,Unsatisfactory,,92,:robot:_primary +validation-38,Zero check is missing on function _get_amount_1_delta in sqrt_price_math,,No security impact to the protocol or to the users described,Unsatisfactory,,99,:robot:_primary +validation-46,get_max_tick function missing validation in tick_math,,No security impact to the protocol or to the users described,Unsatisfactory,,54,:robot:_primary +validation-16,Incorrect slippage handling in `swap_internal()`,validation-16,"Seems QA as this seems to not have any security impact, e.g, fix will not provide slippage protection which is the issue that is being claimed by warden.",Satisfactory,https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/seawater/src/lib.rs#L183-L186,40,:robot:_primary +validation-48,Token is refunded wrongly in the two-step swap,validation-15,Incorrect refunded token,Satisfactory,https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/seawater/src/lib.rs#L292,60,:robot:_02_group +validation-7,Tokens are pulled from users without verifying pool status contrary to requirement,validation-20,Users can add liqudity even if pool is not enabled,Satisfactory,https://github.com/code-423n4/2024-10-superposition/blob/main/pkg/seawater/src/pool.rs#L86,65,:robot:_01_group +validation-12,Missing access control in `create_pool_D650_E2_D0()` allows for unauthorized pool creation,validation-12,Seems that the function is indeed intended to be access-controlled,Satisfactory,https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/seawater/src/lib.rs#L802-L834,73,:robot:_primary +validation-6,Missing `sqrt_price` validation during pool creation/update may render all swaps with MAX `price_limit` inexecutable,validation-6,Seems like QA as is an edge case without loss of funds. Leaving as satisfactory for visibility,Satisfactory,https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/seawater/src/pool.rs#L238-L257,111,:robot:_primary +validation-14,Incorrect token pull logic in `swap_2_internal_erc20()`,validation-17,Incorrect refund during swaps,Satisfactory,https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/seawater/src/lib.rs#L287-L297,43,:robot:_02_group +validation-15,Incorrect token refunded in `swap_2_internal_erc20()`,validation-15,Incorrect refunded token,Satisfactory,https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/seawater/src/lib.rs#L292,46,:robot:_02_group \ No newline at end of file