Skip to content
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

Borrower can fully bypass the onRepay hook #61

Open
howlbot-integration bot opened this issue Sep 20, 2024 · 5 comments
Open

Borrower can fully bypass the onRepay hook #61

howlbot-integration bot opened this issue Sep 20, 2024 · 5 comments
Labels
bug Something isn't working downgraded by judge Judge downgraded the risk level of this issue grade-b primary issue Highest quality submission among a set of duplicates Q-16 QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax 🤖_117_group AI based duplicate group recommendation sponsor disputed Sponsor cannot duplicate the issue, or otherwise disagrees this is an issue sufficient quality report This report is of sufficient quality

Comments

@howlbot-integration
Copy link

Lines of code

https://github.com/code-423n4/2024-08-wildcat/blob/main/src/market/WildcatMarketBase.sol#L406

Vulnerability details

Impact

Borrower can bypass calls to the onRepay hook

Proof of Concept

Within the protocol, users are free to implement markets with a set of hooks, including a onRepay hook which is intended to be called any time a repayment is made.

  function _repay(MarketState memory state, uint256 amount, uint256 baseCalldataSize) internal {
    if (amount == 0) revert_NullRepayAmount();
    if (state.isClosed) revert_RepayToClosedMarket();

    asset.safeTransferFrom(msg.sender, address(this), amount);
    emit_DebtRepaid(msg.sender, amount);

    // Execute repay hook if enabled
    hooks.onRepay(amount, state, baseCalldataSize);
  }

However, the problem is that any funds transferred directly to the contract are treated as a repayment by the borrower. This does allow the borrower, any time they wish to make a repayment, they can just send the funds to the contract and avoid the onRepay hook (as it may apply restrictions, extra fees or generally - anything)

This basically makes the onRepay hook useless.

Tools Used

Manual review

Recommended Mitigation Steps

Consider either using internal accounting or removing the onRepay hook.

Assessed type

Context

@howlbot-integration howlbot-integration bot added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value 🤖_117_group AI based duplicate group recommendation bug Something isn't working primary issue Highest quality submission among a set of duplicates sufficient quality report This report is of sufficient quality labels Sep 20, 2024
howlbot-integration bot added a commit that referenced this issue Sep 20, 2024
@laurenceday
Copy link

laurenceday commented Sep 25, 2024

I was speaking to Dillon about this, and while the hook is there for consistency (given that the major functions each have one), in practice I can't think of any kind of hook behaviour we'd actually want to enforce on this, so it's somewhat moot [and the filing recognises this given that one of the mitigations is just 'lose it'].

With that said, I've mentioned in a few other places that repay is a bit of a strange duck compared to the others because it macros functionality that we can't avoid and is only really there as a QOL improvement.

Will come back to this one, but leaning towards an acknowledge.

@d1ll0n
Copy link

d1ll0n commented Oct 2, 2024

I wouldn't consider this a medium as the onRepay hook is intended to be used when the repay function is actually used, not just any time the market is updated after having received tokens (in which case we have no way of knowing who sent it). Still a decent QA finding for pointing out that onRepay is largely useless though.

@d1ll0n d1ll0n added the sponsor disputed Sponsor cannot duplicate the issue, or otherwise disagrees this is an issue label Oct 2, 2024
@3docSec
Copy link

3docSec commented Oct 3, 2024

It appears to me that hooks are set by the borrower at market deployment. So the borrower can repay debt and bypass their own hooks; looks indeed more like a QA than an M finding.

@c4-judge c4-judge added downgraded by judge Judge downgraded the risk level of this issue QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax and removed 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value labels Oct 3, 2024
@c4-judge
Copy link
Contributor

c4-judge commented Oct 3, 2024

3docSec changed the severity to QA (Quality Assurance)

@c4-judge
Copy link
Contributor

c4-judge commented Oct 3, 2024

3docSec marked the issue as grade-b

@C4-Staff C4-Staff added the Q-16 label Oct 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working downgraded by judge Judge downgraded the risk level of this issue grade-b primary issue Highest quality submission among a set of duplicates Q-16 QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax 🤖_117_group AI based duplicate group recommendation sponsor disputed Sponsor cannot duplicate the issue, or otherwise disagrees this is an issue sufficient quality report This report is of sufficient quality
Projects
None yet
Development

No branches or pull requests

5 participants