Borrower Can Permanently Invalidate Push Provider Credentials Through Block/Unblock Actions

[howlbot-integration[bot]]

Lines of code

https://github.com/code-423n4/2024-08-wildcat/blob/fe746cc0fbedc4447a981a50e6ba4c95f98b9fe1/src/access/AccessControlHooks.sol#L447-L449

Vulnerability details

The current implementation allows the borrower to permanently invalidate credentials provided by push providers through a sequence of blocking and unblocking actions. This vulnerability undermines the access control system and gives the borrower unintended power over lender credentials.

Proof of Concept

A push provider grants a credential to a lender:

function _grantRole(
    RoleProvider callingProvider,
    address account,
    uint32 roleGrantedTimestamp
) internal {
    // ...
    _setCredentialAndEmitAccessGranted(status, callingProvider, account, roleGrantedTimestamp);
}

The borrower can then invalidate this credential:

function blockFromDeposits(address account) external onlyBorrower {
    LenderStatus memory status = _lenderStatus[account];
    if (status.hasCredential()) {
        status.unsetCredential();
        emit AccountAccessRevoked(account);
    }
    status.isBlockedFromDeposits = true;
    _lenderStatus[account] = status;
    emit AccountBlockedFromDeposits(account);
}

The borrower can then unblock the lender, but the credential remains invalidated:

function unblockFromDeposits(address account) external onlyBorrower {
    LenderStatus memory status = _lenderStatus[account];
    status.isBlockedFromDeposits = false;
    _lenderStatus[account] = status;
    emit AccountUnblockedFromDeposits(account);
}

However, push provider credentials can't be refreshed.

Exploit scenario:

1. Alice receives a credential from a push provider.
2. The borrower calls blockFromDeposits(alice), clearing Alice's credential.
3. The borrower calls unblockFromDeposits(alice), unblocking Alice but not restoring her credential.
4. Alice's push provider credential is now permanently invalidated.
5. Alice can't participate in the market until the push provider manually grants a new credential again.

This allows the borrower to arbitrarily and permanently revoke access granted by push providers, which is likely not the intended behavior of the system.

Recommended Mitigation Steps

Separate blocking from credential management.

Assessed type

Access Control

[d1ll0n]

There's nothing permanent about this except the erasure of the prior credential (and credentials are generally expected to be temporary). Blocking has the effect of revoking any existing credentials. Unblocking only restores the ability for a lender to receive a credential, it's not intended to restore the credential to what it was originally

However, push provider credentials can't be refreshed.

If it's a push provider, it couldn't be refreshed regardless (if it were to expire). The fact the lender has a credential in the first place means we should assume that credential can be granted again absent an issue on the role provider which prevents it from granting it a second time, which would be out of scope. Nothing fundamentally changes on the lender's account relative to what it would have been if it had never received the credential.

[3docSec]

Marking as invalid as it looks the intended behavior. If I get this right, nothing prevents the borrower from restoring a lender's credentials after unblocking them.

[c4-judge]

3docSec marked the issue as unsatisfactory: Invalid