Core Contracts

Summary

In the veRAACToken contract, there exists a function named recordVote that is intended to record a user's vote for a proposal. This function requires only the voter's address and the proposal ID. If the voter has not already cast a vote—as determined by the _hasVotedOnProposal mapping—the function records the vote by setting the corresponding entry in this mapping to true and emits a VoteCast event. This design is intended to prevent double voting and ensure that each voter’s participation is recorded only once.

However, the recordVote function is implemented without critical access control modifiers such as nonReentrant, whenNotPaused, or a specific access control modifier (e.g., onlyAdmin or onlyGovernance). As a result, the function is publicly accessible, creating a significant security vulnerability. Malicious actors can exploit this oversight to manipulate the governance voting mechanism by recording votes on behalf of any voter, thereby rigging the outcome of proposals. This flaw not only jeopardizes the integrity of the governance process by distorting the voting quorum but also creates a denial of service (DoS) for legitimate voters, as their ability to cast votes may be entirely blocked. Ultimately, this vulnerability can erode trust in the protocol, damage its market reputation, and lead to reduced user participation.

Vulnerability Details

The recordVote function is defined as follows:

In this implementation, the function does not enforce any restrictions on who can call it. The absence of access control modifiers means that any external entity can invoke recordVote and specify an arbitrary voter address along with a proposal ID. Consequently, a malicious actor could intentionally mark legitimate voters as having already voted, effectively preventing them from participating in the governance process. This exploitation would enable an attacker to rig the voting results by eliminating rivals and manipulating the voting quorum.

Moreover, by marking voters as having voted when they have not, the function creates a denial of service (DoS) scenario for those voters. Legitimate voters may be unable to cast their votes if their addresses are falsely recorded as having already participated. This not only undermines the democratic process but also significantly degrades the overall integrity and reliability of the governance mechanism within the protocol.

Proof of Concept

To demonstrate this vulnerability, the following Proof of Concept (PoC) is provided. The PoC is written using the Foundry tool.

1. Step 1: Create a Foundry project and place all the contracts in the src directory.

2. Step 2: Create a test directory and a mocks folder within the src directory (or use an existing mocks folder).

3. Step 3: Create all necessary mock contracts, if required.

4. Step 4: Create a test file (with any name) in the test directory.

5. Step 5: Add the following test PoC in the test file, after the setUp function.

6. Step 6: To run the test, execute the following commands in your terminal:

7. Step 7: Review the output. The expected output should indicate that malicious actor can rig the Governance voting by providing any voter and any proposal ID.

As demonstrated, the test confirms that the malicious actors can rig the Governance Proposal Voting and this hints that voters afterwards will face a Denial of Service (DoS).

Impact

• Governance Manipulation:
  The lack of proper access control in the recordVote function permits any external actor to record votes on behalf of any voter. This capability can be exploited to manipulate governance outcomes by marking certain voters as having already cast their ballots, even if they have not. Such unauthorized actions can fundamentally alter the balance of voting power within the protocol.

• Distortion of Voting Quorum:
  By falsely recording votes, a malicious actor can artificially inflate the number of votes already cast. This misrepresentation may lead to a higher perceived participation rate, thereby distorting the quorum requirements. As a result, legitimate proposals may be incorrectly deemed to have failed due to a reduced number of actual votes, or conversely, proposals may pass under skewed conditions that do not reflect the genuine consensus of the community.

• Voter Denial of Service:
  Malicious manipulation of the vote-recording mechanism can prevent legitimate voters from casting their votes. When a voter’s address is falsely flagged as having already voted, it creates a denial of service (DoS) for that voter. This effectively blocks the affected users from participating in governance, further skewing the voting process in favor of attackers.

• Erosion of Trust in Governance:
  The ability for any party to tamper with vote records severely undermines confidence in the integrity of the governance process. Stakeholders may perceive the system as vulnerable to manipulation, leading to decreased participation and a loss of trust in the protocol's decision-making framework.

• Potential Market Reputation Damage:
  If the governance process is compromised, the protocol’s reputation in the broader market can suffer significantly. Investors and users may be deterred from participating in a system where the fairness and accuracy of governance decisions are in question, which could have long-term negative implications on the protocol’s viability and market value.

Tools Used

• Manual Review

• Foundry

• Console Log (Foundry)

• Chisel (Foundry)

Recommendations

• Implement Access Control Modifiers:
  Introduce appropriate access control modifiers such as nonReentrant and whenNotPaused to secure the recordVote function. Additionally, restrict access by incorporating a modifier like onlyAdmin or onlyGovernance to ensure that only authorized entities can record votes.

• Validate Caller Authorization:
  Modify the function to verify that the caller is an authorized entity (for example, a designated voting module or the governance contract itself) rather than allowing public access. This will prevent unauthorized vote recording and ensure that only genuine votes are counted.

Below is a detailed vulnerability report addressing the phishing scenario in the veRAACToken contract, where a malicious token holder ("Devil") can exploit the unmodified approval mechanism to phish another user ("Alice") for governance tokens and voting power.