Potential Bypass of Era Consistency Check in Proposal Execution #142
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
🤖_primary
AI based primary recommendation
sufficient quality report
This report is of sufficient quality
Lines of code
https://github.com/code-423n4/2024-07-reserve/blob/3f133997e186465f4904553b0f8e86ecb7bbacbf/contracts/plugins/governance/Governance.sol#L136-L145
Vulnerability details
Impact
The current implementation performs the
startedInSameEra()
check after the_execute
function. This sequence creates a vulnerability where the era consistency check could be bypassed if the_execute
function contains operations that can prematurely terminate execution.This vulnerability could lead to proposals being executed in a different era than they were proposed, potentially causing:
Proof of Concept
_execute
function encounters one of the following scenarios:a. Gas exhaustion: A complex operation consumes all available gas, causing the transaction to fail before reaching the
startedInSameEra()
check.b. Non-reverting opcode error: An assembly-level operation results in an error that doesn't trigger a revert (e.g., an invalid jump destination or stack underflow).
startedInSameEra()
check.Tools Used
Manual Review
Recommended Mitigation Steps
Move the
startedInSameEra()
check to the beginning of the proposal execution process, before any actions in_execute
are performed. For example: ```solidityfunction executeProposal(uint256 proposalId) public {
require(startedInSameEra(proposalId), "new era");
super._execute(proposalId, targets, values, calldatas, descriptionHash);
}
The text was updated successfully, but these errors were encountered: