-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
H-01 LibHooksConfig.setHooksAddress
is updating address
incorrectly
#85
Comments
3docSec changed the severity to QA (Quality Assurance) |
3docSec marked the issue as grade-c |
@3docSec, thank you for your judgment and marking this as a duplicate of issue #3. In that report, the warden only mentioned that it affects cases where Full POC: Copy below code into
|
I think like with #3 the severity is inflated for two reasons:
I do appreciate the finding though, this was definitely a mistake. |
I agree that borrowers need to be whitelisted, but wildcat markets operate based on borrowers. If no borrowers are willing to borrow funds, the wildcat market would halt. Therefore, from the protocol’s perspective, it will aim to whitelist as many borrowers as possible.
I agree with this, but once someone manages to exploit it, regular users won’t have a way to know whether the deployed market is a trusted implementation or not. Currently, if someone wants to verify a deployed hook instance, the flow is as follows:
This returns the implementation of the given hook, but due to the Therefore, users must rely on manually verifying the exact bytecode for specific hooks. I believe the severity should be high because there is a clear path to steal or freeze all lender funds through the hooks. This is critical since the hook instance is responsible for verifying all actions when users deposit or withdraw from the market. |
While I would normally agree with you on a different protocol, we have to contextualize this statement:
For Wildcat we have to remember that the borrower is considered a trusted entity (because of the undercollateralized nature of the protocol), so their actions are too as a consequence. So I agree there are nuances of this finding that are different from #3, but we still are in QA territory |
3docSec marked the issue as grade-b |
Lines of code
https://github.com/code-423n4/2024-08-wildcat/blob/main/src/types/HooksConfig.sol#L84-L94
Vulnerability details
Description: Currently, the wildcat protocol is using
HooksConfig
for deploying markets, which is responsible for enabling various features in a particular market.The current
HookConfig
encoding is as follows:The
LibHooksConfig.setHooksAddress()
function is responsible for updating the newhookAddress
in thehookConfig
, but it is only clearing the leftmost96 bits
instead of160 bits
.Impact:
hookFactory.deployMarketAndHooks
, which has a non-zero address inDeployMarketInputs.parameters.hooks
.Proof of Concept (PoC):
Recommendation:
Assessed type
Error
The text was updated successfully, but these errors were encountered: