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

Tolerance is not enforced during a flash governance decision #306

Closed
code423n4 opened this issue Feb 2, 2022 · 3 comments
Closed

Tolerance is not enforced during a flash governance decision #306

code423n4 opened this issue Feb 2, 2022 · 3 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 disagree with severity Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments) resolved Finding has been patched by sponsor (sponsor pls link to PR containing fix) sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")

Comments

@code423n4
Copy link
Contributor

Handle

shw

Vulnerability details

Impact

Most of the functions with a governanceApproved modifier call flashGoverner.enforceTolerance to ensure the provided parameters are restricted to some range of their original values. However, in the governanceApproved modifier, flashGoverner.setEnforcement(true); is called after the function body is executed, and thus the changed values are not restricted during the function execution.

An attacker can exploit this bug to change some critical parameters to arbitrary values by flash governance decisions. The effect will last until the community executes another proposal to correct the values. In the meanwhile, the attacker may make use of the corrupted values to launch an attack.

Proof of Concept

  1. An attacker executes a flash governance decision, for example, the adjustSoul function of Limbo, and sets the fps of a soul to an extremely large value.
  2. During the flash governance decision, some of his assets, for example, EYE, are locked in the FlashGovernanceArbiter contract.
  3. He calls claimReward to get his rewards on the corresponding soul (assume that he has staked some number of the token before). Because of the manipulated fps, he gets a large number of Flan tokens as the reward.
  4. Surely, he will lose his EYE tokens because of the malicious flash governance decision. However, as long as the attacker gets large enough Flan tokens, he is incentivized to launch such an attack.

Referenced code:
DAO/Governable.sol#L46-L57
Limbo.sol#L380-L381
Limbo.sol#L327-L329
Limbo.sol#L530
Limbo.sol#L628-L630

Recommended Mitigation Steps

Rewrite the _governanceApproved function and the governanceApproved modifier as follows:

  function _governanceApproved(bool emergency) internal {
    bool successfulProposal = LimboDAOLike(DAO).successfulProposal(msg.sender);
    if (successfulProposal) {
      flashGoverner.setEnforcement(false);
    } else if (configured) {
      flashGoverner.setEnforcement(true);
      flashGoverner.assertGovernanceApproved(msg.sender, address(this), emergency);
    }
  }

  modifier governanceApproved(bool emergency) {
    _governanceApproved(emergency);
    _;
  }
@code423n4 code423n4 added 3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working labels Feb 2, 2022
code423n4 added a commit that referenced this issue Feb 2, 2022
@gititGoro
Copy link
Collaborator

So this is a vulnerability for the very first execution of flashgovernance decision on a contract, after which it's safe. This is the type of thing that won't be acted upon because it will have gone away by the time the public interacts with Limbo. However, it is technically true so I'm confirming the issue.

@gititGoro gititGoro added disagree with severity Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments) sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") labels Feb 5, 2022
@gititGoro gititGoro added the unresolved indicate confirmed issues that haven't been resolved with a PR label Feb 12, 2022
@jack-the-pug
Copy link
Collaborator

Valid finding, but the conditions are quite strict, downgraded to Med.

@jack-the-pug jack-the-pug added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value and removed 3 (High Risk) Assets can be stolen/lost/compromised directly labels Feb 27, 2022
@gititGoro
Copy link
Collaborator

FIX Behodler/limbo#13

Note: an additional flash loan bug that wasn't picked up in the audit was fixed.

@gititGoro gititGoro added resolved Finding has been patched by sponsor (sponsor pls link to PR containing fix) and removed unresolved indicate confirmed issues that haven't been resolved with a PR labels Jun 25, 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 disagree with severity Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments) resolved Finding has been patched by sponsor (sponsor pls link to PR containing fix) sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Projects
None yet
Development

No branches or pull requests

3 participants