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

Consent in MutualConsent is not removable #61

Closed
code423n4 opened this issue Nov 5, 2022 · 2 comments
Closed

Consent in MutualConsent is not removable #61

code423n4 opened this issue Nov 5, 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-33 satisfactory Finding meets requirement

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/debtdao/Line-of-Credit/blob/audit/code4rena-2022-11-03/contracts/utils/MutualConsent.sol#L38-L60
https://github.com/debtdao/Line-of-Credit/blob/audit/code4rena-2022-11-03/contracts/utils/MutualConsent.sol#L31-L36

Vulnerability details

Impact

Borrower or Lender can't remove their consent from MutualConsent if they need.

Proof of Concept

MutualConsent has mutualConsent modifier which is used to protect functions that need to have consent of 2 parties before call. Example of such function is LineOfCredit.addCredit.

This is how mutual consent checking works
https://github.com/debtdao/Line-of-Credit/blob/audit/code4rena-2022-11-03/contracts/utils/MutualConsent.sol#L38-L60

    function _mutualConsent(address _signerOne, address _signerTwo) internal returns(bool) {
        if(msg.sender != _signerOne && msg.sender != _signerTwo) { revert Unauthorized(); }


        address nonCaller = _getNonCaller(_signerOne, _signerTwo);


        // The consent hash is defined by the hash of the transaction call data and sender of msg,
        // which uniquely identifies the function, arguments, and sender.
        bytes32 expectedHash = keccak256(abi.encodePacked(msg.data, nonCaller));


        if (!mutualConsents[expectedHash]) {
            bytes32 newHash = keccak256(abi.encodePacked(msg.data, msg.sender));


            mutualConsents[newHash] = true;


            emit MutualConsentRegistered(newHash);


            return false;
        }


        delete mutualConsents[expectedHash];


        return true;
    }

As you can see the function store consent of first caller and then waits when another caller will call same function.
There is no any ability to remove this contest.

How this can be used?
For example at t1 lender and borrower aggreed on some credit for amount of tokens and specific fee rates. Then borrower calls createCredit and his consent is stored.
But lender do not call createCredit.
After some time smth happened and rates changed, so it's not good credit conditions for a borrower anymore, but very good for lender.
And lender calls createCredit. As borrower consent already stored, this credit will be created and fees will start accumulate.

Tools Used

VsCode

Recommended Mitigation Steps

Add ability to remove consent, or think about some expiration time for consents.

@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 Nov 5, 2022
code423n4 added a commit that referenced this issue Nov 5, 2022
@c4-judge
Copy link
Contributor

dmvt marked the issue as duplicate of #33

@c4-judge
Copy link
Contributor

c4-judge commented Dec 6, 2022

dmvt marked the issue as satisfactory

@c4-judge c4-judge added the satisfactory Finding meets requirement label Dec 6, 2022
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-33 satisfactory Finding meets requirement
Projects
None yet
Development

No branches or pull requests

2 participants