Arbitrum Security Council Election System - Daniel526's results

A suite of scaling solutions providing environments with high-throughput, low-cost smart contracts, backed by industry-leading proving technology rooted in Ethereum.

General Information

Platform: Code4rena

Start Date: 03/08/2023

Pot Size: $90,500 USDC

Total HM: 6

Participants: 36

Period: 7 days

Judge: 0xean

Total Solo HM: 1

Id: 273

League: ETH

Arbitrum Foundation

Findings Distribution

Researcher Performance

Rank: 3/36

Findings: 1

Award: $9,842.64

🌟 Selected for report: 1

🚀 Solo Findings: 1

Findings Information

🌟 Selected for report: Daniel526

Also found by: Daniel526

Labels

bug
2 (Med Risk)
satisfactory
duplicate-82

Awards

9842.6401 USDC - $9,842.64

External Links

Lines of code

https://github.com/ArbitrumFoundation/governance/blob/c18de53820c505fc459f766c1b224810eaeaabc5/src/security-council-mgmt/governors/modules/SecurityCouncilMemberElectionGovernorCountingUpgradeable.sol#L86-L140

Vulnerability details

The contract design could lead to a conflict between the process of removing a Security Council member and an ongoing Security Council election, potentially impacting the fairness and integrity of both processes.

Impact

The potential conflict between a Security Council removal proposal and an ongoing election could have several negative impacts. It might compromise the fairness of the election process, leading to inaccurate representation of the community's preferences in the newly elected members. This misalignment could undermine the DAO's governance and risk management mechanisms.

Proof of Concept

The provided contract governs the election and removal of Security Council members within the Arbitrum DAO. However, it does not explicitly prevent a situation where a governance proposal to remove a Security Council member coincides with an ongoing election process to select new Security Council members. Such a scenario could lead to unintended consequences and conflicts.

In the code, the contract does not contain mechanisms to prevent or handle cases where a removal proposal affects the outcome of an ongoing election. This omission could undermine the democratic nature of the election process and the DAO's ability to remove council members based on community sentiment. Assume we have an ongoing Security Council election proposal (Proposal A) with contenders being voted upon. At the same time, there is another ongoing governance proposal (Proposal B) to remove a Security Council member.

  1. The _countVote function for Proposal A is processing votes for contenders.
  2. Before the vote counting is complete, the proposal to remove a Security Council member (Proposal B) passes and is executed.
  3. The removal of the Security Council member changes the composition of the Security Council.
  4. The _countVote function for Proposal A continues processing votes using the old Security Council composition, leading to inaccurate counting and potential issues.
  • In this scenario, the vulnerability arises because the _countVote function does not account for the dynamic changes that can occur in the Security Council composition due to ongoing removal proposals. This misalignment with the intended process outlined in the Arbitrum DAO constitution can result in inaccurate election results and undermine the democratic process.

Tools Used

Manual

To mitigate this issue and align with the Arbitrum DAO constitution, the contract should incorporate measures to prevent overlap between removal proposals and ongoing elections. This could involve introducing rules that prioritize one process over the other during specific timeframes or defining clear procedures for handling such situations.

For instance, the DAO could consider a mitigation strategy that involves temporarily suspending ongoing elections if a removal proposal is initiated. This would allow the DAO to address the removal proposal before proceeding with the election process, ensuring that both processes are independent and aligned with the DAO's intentions.

Assessed type

Invalid Validation

#0 - c4-pre-sort

2023-08-13T18:30:43Z

0xSorryNotSorry marked the issue as duplicate of #82

#1 - c4-judge

2023-08-18T23:54:34Z

0xean marked the issue as satisfactory

Findings Information

🌟 Selected for report: Daniel526

Also found by: Daniel526

Labels

bug
2 (Med Risk)
primary issue
satisfactory
selected for report
sponsor acknowledged
M-05

Awards

9842.6401 USDC - $9,842.64

External Links

Lines of code

https://github.com/ArbitrumFoundation/governance/blob/c18de53820c505fc459f766c1b224810eaeaabc5/src/security-council-mgmt/SecurityCouncilManager.sol#L124-L141

Vulnerability details

The contract SecurityCouncilManager in the Arbitrum DAO's security council system has an inconsistency in its cohort replacement process. This inconsistency could potentially lead to a situation where a member is present in both the old and new cohorts simultaneously, contradicting the governance rules set out in the DAO's constitution.

Impact

The inconsistency in the cohort replacement process could lead to a situation where a member is elected to a new cohort while also remaining in the old cohort during ongoing elections. This can create confusion, undermine the democratic process, and potentially compromise the integrity of Security Council decisions. Such a scenario directly contradicts the DAO's constitution, which requires careful handling of cohort replacement to avoid conflicts.

Proof of Concept

The Arbitrum DAO's constitution outlines a careful process for replacing cohorts of Security Council members to avoid race conditions and operational conflicts, particularly during ongoing elections. However, the contract implementation lacks the necessary checks to ensure that cohort replacement aligns with ongoing governance activities.

The replaceCohort function is responsible for replacing a cohort with a new set of members. In this function, the old cohort is immediately deleted, and the new cohort is added. This process, while ensuring that only the new members are present in the cohort after replacement, does not account for potential ongoing elections or concurrent transactions.

function replaceCohort(address[] memory _newCohort, Cohort _cohort)
    external
    onlyRole(COHORT_REPLACER_ROLE)
{
    if (_newCohort.length != cohortSize) {
        revert InvalidNewCohortLength({cohort: _newCohort, cohortSize: cohortSize});
    }

    // Delete the old cohort
    _cohort == Cohort.FIRST ? delete firstCohort : delete secondCohort;

    // Add members of the new cohort
    for (uint256 i = 0; i < _newCohort.length; i++) {
        _addMemberToCohortArray(_newCohort[i], _cohort);
    }

    _scheduleUpdate();
    emit CohortReplaced(_newCohort, _cohort);
}

Tools Used

Manual

One possible mitigation is to introduce a mechanism that prevents cohort replacement while an election is ongoing.

Assessed type

Invalid Validation

#0 - c4-pre-sort

2023-08-13T18:30:08Z

0xSorryNotSorry marked the issue as primary issue

#1 - c4-sponsor

2023-08-14T22:30:54Z

DZGoldman marked the issue as sponsor acknowledged

#2 - c4-judge

2023-08-18T23:52:37Z

0xean marked the issue as satisfactory

#3 - c4-judge

2023-08-18T23:54:36Z

0xean marked the issue as selected for report

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter