Closed c4-bot-3 closed 8 months ago
The issue is well demonstrated, properly formatted, contains a coded POC. Marking as HQ.
0xSorryNotSorry marked the issue as high quality report
0xSorryNotSorry marked the issue as primary issue
Acknowledging, I disagree with severity because no user funds are at risk and there is always the possibility to atomically create a term + propose an onboarding for it. There is no economic value to this attack and it can be protected against, so I don't think anyone will do it. Feels more like QA/info to me.
It doesn't hurt to prevent proposal cancellations (through a simple override that reverts) in LendingTermOnboarding because I can't think of any legitimate case where a proposal needs to be cancelled (users can still vote against or veto the addition of the term).
One block after proposing, the vote starts and it is not possible to cancel anymore.
eswak (sponsor) acknowledged
eswak marked the issue as disagree with severity
Agree with sponsor that this issue should be a low/QA based on its impact.
Trumpero changed the severity to QA (Quality Assurance)
Trumpero marked the issue as grade-a
Trumpero marked the issue as grade-c
Dear @Trumpero,
I appreciate your time and attention to this matter.
I would like to bring to your attention what I believe to be a significant issue, potentially categorized as at least a "Medium" severity concern. This issue revolves around a clear vulnerability that could be exploited as a Denial of Service (DoS) attack vector. Remarkably, this attack can be executed with just a single transaction per week, emphasizing its critical nature.
In particular, I'd like to draw your attention to the gas inefficiency of the createTerm function as a solution because it is gas inefficient for the caller and it does not guarantee that malicious user won't block the proposal of it again.
Furthermore, it's essential to differentiate this issue from others, such as #244, #85, #1257, #704, and #665, as they pertain to entirely different problems, which are for cancel
function in another contract.
Hi @Trumpero,
This issue has a coded PoC and was rated a high-quality report
.
Why did it get a grade-c
/unsatisfactory
?
Further, compared to other issues in the same category, #665, #588, and #344, why are they satisfactory for receiving awards?
What were the judging criteria you used behind them?
@NicolaMirchev This issue should be a low/info because it only leads to a temporary and preventable DOS situation, proposers can always createTerm and proposeOnboard in the same transaction (using multicall or an external contract). I believe duplicates are correct since they all mention that Governor::cancel()
hasn't been removed and can still be used to cancel their own proposal
@serial-coder When an issue is downgraded to QA, it will be included in the QA report of that warden. After combining all QA issues of this warden, their QA point is still not enough to reach grade-b in my evaluation. Therefore, all issues of this warden are marked as grade-c. You can find more information of my QA evaluation in this comment.
Lines of code
https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/2376d9af792584e3d15ec9c32578daa33bb56b43/src/governance/LendingTermOnboarding.sol#L211 https://github.com/OpenZeppelin/openzeppelin-contracts/blob/09329f8a18f08df65863a5060f6e776bf7fccacf/contracts/governance/Governor.sol#L434 https://github.com/OpenZeppelin/openzeppelin-contracts/blob/09329f8a18f08df65863a5060f6e776bf7fccacf/contracts/governance/Governor.sol#L572 https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/2376d9af792584e3d15ec9c32578daa33bb56b43/src/governance/LendingTermOnboarding.sol#L188-L191
Vulnerability details
The
LendingTermOnboarding
contract allows guild holders to poll to onboard a lending term for issuing loans by creating an onboarding proposal for the lending term through theproposeOnboard()
. If the voting weight is enough, the lending term will be onboarded after the Timelock delay.Nevertheless, the
proposeOnboard()
has a vulnerability that allows an attacker to perform a denial-of-service (DoS) attack, blocking the creation of an onboarding proposal for their target lending term. The attacker can even block their target lending term from onboarding permanently with budget costs if they will.Vulnerability Details
The following illustrates the attack steps:
proposeOnboard()
.LendingTermOnboarding::proposeOnboard()
to create an onboarding proposal for the target term.Governor::cancel()
to cancel the created proposal.proposeOnboard()
has a check for the cooldown period of 7 days (i.e.,MIN_DELAY_BETWEEN_PROPOSALS
constant).Because the
proposeOnboard()
has a cooldown period of 7 days for each lending term, the attacker has to execute the DoS operation only every 7 days to block their target lending term from being onboarded. Hence, the attacker's costs are very budgeted compared to the damage to the protocol and users.Please refer to the
Proof of Concept
section for the coded PoC.@1 -- The attacker cancels the created onboarding proposal
: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/09329f8a18f08df65863a5060f6e776bf7fccacf/contracts/governance/Governor.sol#L434@2 -- The onboarding proposal for each term has a cooldown period of 7 days
: https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/2376d9af792584e3d15ec9c32578daa33bb56b43/src/governance/LendingTermOnboarding.sol#L188-L191@3 -- The canceled onboarding proposal can no longer be voted by anyone
: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/09329f8a18f08df65863a5060f6e776bf7fccacf/contracts/governance/Governor.sol#L572Impact
Because the
proposeOnboard()
has a cooldown period of 7 days for each lending term, the attacker has to execute the DoS operation only every 7 days to block their target lending term from being onboarded.Hence, the attacker's costs are very budgeted compared to the damage to the protocol and users.
Proof of Concept
This section provides a coded PoC.
Place the
testPoCLendingTermOnboardingDoS()
in the.test/unit/governance/LendingTermOnboarding.t.sol
file and run the test using theforge test --match-test testPoCLendingTermOnboardingDoS -vvv
command.The PoC explains the attack steps described in the
Vulnerability Details
section.Tools Used
Manual Review
Recommended Mitigation Steps
There can be a handful of solutions depending on the developer's decision.
One possible solution is to allow some authorized users/admins to execute the
proposeOnboard()
but override the cooldown period check. This solution can prevent the attacker's front-running attack as they will stick around the cooldown period as standard users.Assessed type
DoS