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

NFT are no longer on the allowed list and can still increase debt #223

Closed
code423n4 opened this issue Dec 21, 2022 · 2 comments
Closed

NFT are no longer on the allowed list and can still increase debt #223

code423n4 opened this issue Dec 21, 2022 · 2 comments
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working duplicate-91 satisfactory satisfies C4 submission criteria; eligible for awards

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/with-backed/papr/blob/9528f2711ff0c1522076b9f93fba13f88d5bd5e6/src/PaprController.sol#L138-L145
https://github.com/with-backed/papr/blob/9528f2711ff0c1522076b9f93fba13f88d5bd5e6/src/PaprController.sol#L493-L517

Vulnerability details

Impact

NFT are no longer on the allowed list and can still increase debt

PaprController restricts which NFTs are allowed to be used as collateral by isAllowed.
When an NFT is already at risk and no longer suitable as collateral, owner can set isAllowed[nft] to false
so that subsequent calls to addCollateral() can not be used as collateral for this NFT, so as to avoid the risk of this NFT is no longer safe.

But here is a problem, the user has been added as collateral in the previous, the user can still continue to borrow through increaseDebt(), and did not check that this NFT is no longer allowed.
I think this is unreasonable, if it is no longer in the allowed list, should not be able to borrow through it again. Avoid bringing the risk of funds.

Other:liquidating/repaying is ok, even if NFT is not on the list

Proof of Concept

As follows, increaseDebt() does not check whether the NFT is still on the allowed list

    function _increaseDebt(
        address account,
        ERC721 asset,
        address mintTo,
        uint256 amount,
        ReservoirOracleUnderwriter.OracleInfo memory oracleInfo
    ) internal {
...
    function _increaseDebt(
        address account,
        ERC721 asset,
        address mintTo,
        uint256 amount,
        ReservoirOracleUnderwriter.OracleInfo memory oracleInfo
    ) internal {


    	/***@audit No check  NFT is no longer in the allowed list *****/ 

        uint256 cachedTarget = updateTarget();

        uint256 newDebt = _vaultInfo[account][asset].debt + amount;
        uint256 oraclePrice =
            underwritePriceForCollateral(asset, ReservoirOracleUnderwriter.PriceKind.LOWER, oracleInfo);

        uint256 max = _maxDebt(_vaultInfo[account][asset].count * oraclePrice, cachedTarget);

        if (newDebt > max) revert IPaprController.ExceedsMaxDebt(newDebt, max);

        if (newDebt >= 1 << 200) revert IPaprController.DebtAmountExceedsUint200();

        _vaultInfo[account][asset].debt = uint200(newDebt);
        PaprToken(address(papr)).mint(mintTo, amount);

        emit IncreaseDebt(account, asset, amount);
    }

Tools Used

Recommended Mitigation Steps

if NFT don't in allowed list will revert

    function _increaseDebt(
        address account,
        ERC721 asset,
        address mintTo,
        uint256 amount,
        ReservoirOracleUnderwriter.OracleInfo memory oracleInfo
    ) internal {

+       if (!isAllowed[address(asset)]) {
+           revert IPaprController.InvalidCollateral();
+       }

        uint256 cachedTarget = updateTarget();

        uint256 newDebt = _vaultInfo[account][asset].debt + amount;
....                
@code423n4 code423n4 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working labels Dec 21, 2022
code423n4 added a commit that referenced this issue Dec 21, 2022
@c4-judge
Copy link
Contributor

trust1995 marked the issue as duplicate of #91

@c4-judge
Copy link
Contributor

trust1995 marked the issue as satisfactory

@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Dec 25, 2022
C4-Staff added a commit that referenced this issue Jan 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working duplicate-91 satisfactory satisfies C4 submission criteria; eligible for awards
Projects
None yet
Development

No branches or pull requests

2 participants