-
Notifications
You must be signed in to change notification settings - Fork 3
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
AccessControlHooks onQueueWithdrawal() does not check if market is hooked which could lead to unexpected errors such as temporary DoS #11
Comments
3docSec changed the severity to QA (Quality Assurance) |
3docSec marked the issue as grade-b |
This previously downgraded issue has been upgraded by 3docSec |
3docSec marked the issue as satisfactory |
3docSec marked the issue as selected for report |
See #83 (comment) |
We don't consider this a real issue, in that we’ve always wanted it to be possible for anyone to call the validate function to poke a credential update. This finding assumes that you have the signature someone else would be using as a credential and generally relies on a specific implementation of the provider that doesn’t actually exist, so there's no need to check It's been upgraded to a Medium, and we're not going to argue with this at this stage. As such, we're acknowledging rather than confirming or disputing simply to put a cap on the report. |
Lines of code
https://github.com/code-423n4/2024-08-wildcat/blob/main/src/access/AccessControlHooks.sol#L812
Vulnerability details
Impact
The
onQueueWithdrawal()
function does not check if the caller is a hooked market, meaning anyone can call the function and attempt to verify credentials on a lender. This results in calls to registered pull providers with arbitrary hookData, which could lead to potential issues such as abuse of credentials that are valid for a short term, e.g. 1 block.Proof of Concept
The
onQueueWithdrawal()
function does not check if the msg.sender is a hooked market, which is standart in virtually all other hooks:https://github.com/code-423n4/2024-08-wildcat/blob/main/src/access/AccessControlHooks.sol#L812
If the caller is not a hooked market, the statement
!isKnownLenderOnMarket[lender][msg.sender]
, will return true, because the lender will be unknown. As a result the_tryValidateAccess()
function will be executed for anylender
and anyhooksData
passed. The call to_tryValidateAccess()
will forward the call to_tryValidateAccessInner()
. Choosing a lender of arbitrary address, sayaddress(1)
will cause the function to attempt to retrieve the credential via the call to _handleHooksData(), since the lender will have no previous provider or credentials.As a result, the _handleHooksData function will forward the call to the encoded provider in the hooksData and will forward the extra hooks data as well, say merkle proof, or any arbitrary malicios data.
https://github.com/code-423n4/2024-08-wildcat/blob/main/src/access/AccessControlHooks.sol#L617
The function call will be executed in tryValidateCredential(), where the extra hookData will be forwarded. As described in the function comments, it will execute a call to
provider.(address account, bytes calldata data)
.This means that anyone can call the function and pass arbitrary calldata. This can lead to serios vulnerabilities as the calldata is passed to the provider.
Consider the following scenario:
By following this scenario, a malicios user can essentially DoS a specific type pull provider.
Depending on implemenation of the pull provider, this can lead to other issues, as the malicios user can supply any arbitrary hookData in the function call.
Recommended Mitigation Steps
Require the caller to be a registered hooked market, same as onQueueWithdrawal() in FixedTermloanHooks
Assessed type
DoS
The text was updated successfully, but these errors were encountered: