Closed howlbot-integration[bot] closed 3 months ago
This is indeed a problem on the test implementations, however TransformERC20
always give ETH as an outputToken
and Uniswav_V3
always give WETH as outputToken
so the validations in the contract are correct and not a vulnerability in the contract itself
koolexcrypto marked the issue as primary issue
koolexcrypto marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2024-05-loop/blob/0dc8467ccff27230e7c0530b619524cc8401e22a/src/PrelaunchPoints.sol#L412 https://github.com/code-423n4/2024-05-loop/blob/0dc8467ccff27230e7c0530b619524cc8401e22a/src/PrelaunchPoints.sol#L414
Vulnerability details
Impact
Calling the 0xAPI for an LRT is might result in
TransformERC20()
(0x415565b0
) selector being returned, even if the exchange that is thesource
of the data isUniswap_V3
. This causes the_validate()
data to revert withWrongSelector("0x415565b0")
every time the user tries to claim/claim and stake theirlpETH
. TheoutputToken
checked by manually decoding the API return data in Remix IDE with the_decodeTransformERC20()
function is set to0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE
-ETH
, so the call toTransformERC20()
should NOT be reverted. This means, that the API return data does not have to necessarily return theUNI_SELECTOR
, when the source is set asUniswap_V3
.The vulnerability is caused by the mitigation of [WP-M3] finding from LoopFi / Prelaunch / LRT #2 audit.
Proof of Concept
To better understand this problem paste the code in this gist to the
PrelaunchPoints0x.test.ts
test file, and run it withyarn hardhat test ./test/PrelaunchPoints0x.test.ts
. It is a simplified version of the original test, where we consider only therswETH
token for clarity. Data resulting from the API call indeed begins with0x415565b0
, suggesting that we should be using theTransformERC20()
function in_fillQuote
. However, we never get to filling the quote, becauseorders[0].source
isUniswap_V3
meaning that theexchangeCode
is0
. In_validateData
the first branch is executed and the code fails due toWrongSelector(0x415565b0)
error as explained before.Tools Used
Manual review
Recommended Mitigation Steps
This problem has to be further investigated and only when 0x API return data is fully predictable, an appropriate mitigation can be developed. However, to simulate successful data validation the following
_validateData()
function implementation, where the_exchange
enum parameter is ignored to allow the TransformERC20 selector- based data to be decoded ( !!! note that this is NOT a safe nor faul proof solution to this vulnerability !!!):This shows, that the return data is indeed correct, the issue lays within the assumption [
source=uniswapv3
impliesselector=UNI_SELECTOR
].Assessed type
Invalid Validation