Open howlbot-integration[bot] opened 2 months ago
Not really a medium in that it doesn't 'matter' for the most part: this is sort of a documentation issue in that we'd never really expect an EOA that wasn't the borrower (which is an EOA provider) to be a role provider.
It's vanishingly unlikely that a borrower is going to add some random arbiter that they don't control - possible that they add another address that THEY control but in that case they might as well use the one that's known to us.
Disputing, but with a light touch: we consider this a useful QA.
Thanks for the context. If we ignore the documentation, the fact that the initial role provider is the borrower, and the NotPullProviderIndex
value that is used in this case makes it clear that the intention is allowing for EOAs to be there.
While not the most requested feature, it's something a borrower may want to do, and given the above, may reasonably expect to see working. For this reason, I think a Med is reasonable because we have marginal I admit, but still tangible, availability impact
3docSec marked the issue as satisfactory
3docSec marked the issue as selected for report
Lines of code
https://github.com/code-423n4/2024-08-wildcat/blob/fe746cc0fbedc4447a981a50e6ba4c95f98b9fe1/src/access/AccessControlHooks.sol#L220 https://github.com/code-423n4/2024-08-wildcat/blob/fe746cc0fbedc4447a981a50e6ba4c95f98b9fe1/src/access/FixedTermLoanHooks.sol#L254
Vulnerability details
Impact
The Documentation suggests that a role provider can be a "push" provider (one that "pushes" credentials into the hooks contract by calling
grantRole
) and a "pull" provider (one that the hook calls viagetCredential
orvalidateCredential
).The documentation also states that:
But in fact, only the initial deployer can be an EOA provider, since it is coded in the constructor. Any other EOA provider that the borrower tries to add via
addRoleProvider
will fail because it does not implement the interface.Proof of Concept
PoC will revert because EOA does not implement interface obviously:
PoC:
Tools Used
Manual Review
Recommended Mitigation Steps
Replace the interface call with a low-level call and check if the user implements the interface in order to be a pull provider:
With this code all logic works as expected, for EOA providers
pullProviderIndex
is set totype(uint24).max
, for contracts - depending on the result of callingisPullProvider
:Assessed type
Invalid Validation