buckyos / sourcedao

SourceDAO

sourcedao's Issues

Security Improvements for proposal contracts

Consider an attack on our centralized backend, where both the backend code and the database can be modified, it is possible to reach the following attack:

1. someone creates a normal project proposal with a proposal id of 100
2. through the code, he created a malicious Token release proposal, the proposal ID is 101
3. by modifying the backend database, the ID of the project proposal is changed to 101 in the backend.
4. when other people vote in the front-end, they see the description of the project proposal, but when they vote, they vote for the malicious proposal 101.
5. when 101 is passed, it can operate the release token interface to release the token to itself.
   In order to stop this attack, we need to add validation to the chain to prevent the backend from voting for the wrong proposal.
   The solution I'm considering is as follows: Use the params[] validation function of the proposal.

• when creating a proposal, fill up the params of the proposal with parameters + type, the type is added to avoid the situation that some simple proposals have a small number of parameters and conflict with other proposals.

  Example: add member: [member address, "addMember"].
  Remove member: [member address, "removeMember"].
  Create project: [budget, issueId, startDate, endDate, "createProject"].

• these parameters are also stored in the backend database

• modify the voting interface in the chain to support(uint proposalId, bytes32[] memory params)
  The params here need to be passed the same as when creating the params.

• when the front-end creates a voting transaction, read out the corresponding parameter list of the proposal from the back-end.

• in the proposal display, the front-end directly read the proposal parameters, and then according to the type, using a template to spell out a human readable description

• the front-end can calculate its own params hash through the proposal parameters, and then compare it with the hash on the chain to determine whether the proposal is valid.

• in order to prevent the front-end code is tampered with, resulting in the creation of transactions using the wrong parameter list, you can consider the front-end encapsulation in electron, and distribute it

If above scheme is applied, then the previous attack, will become:
If the attacker only modifies the proposal ID, then when the front-end is displayed, modification 6 will prevent this proposal from being displayed
If the attacker modifies both the proposal ID and the proposal parameters, then when the front-end is displayed, modification 5 will be displayed as a Token to release the proposal
In both cases, the vote will not succeed and the attack fails
In the case where the back-end code may have been modified, there is no need to do any other validation logic in the backend, because there is a possibility of being bypassed in both cases

Contract Upgrade Does Not Consider the Scenario of Committee Members Losing Their Private Keys

When a committee member initiates a contract upgrade, only that member can cancel the upgrade or execute it based on the voting results. If the initiating committee member loses their private key following the upgrade's initiation, it seems this could potentially halt the entire upgrade process. Is this the case?

Need for Sequential Consistency in Contract Upgrade Proposals to Prevent Potential Concurrency Issues

I believe that contract upgrades are critical operations, and we should prevent potential concurrency issues. For instance, Proposal 1 suggests upgrading the implementation to version 1.1, while Proposal 2 suggests upgrading the implementation to version 1.2. If the approval sequence turns out to be Proposal 2 followed by Proposal 1, the contract will actually be upgraded to version 1.1. From an implementation perspective, we should leverage the incremental nature of proposal IDs for protection. If a later upgrade proposal passes, earlier proposals should not be executable, even if they are passed.

Need for Renaming and Reconsideration of verifyContractUpgrade Function due to its State-Altering Behavior

The implementation of the verifyContractUpgrade function does more than just "verify state"—it actually alters the state. Should we consider renaming and/or adjusting this function to better align with its behavior?

Given the function's current implementation, I am concerned that an approved proposal (especially considering that proposals do not record old implementation addresses) could potentially be repeatedly verified and used to execute upgrade operations.

Include _proposalId in root_merklehash for _propose Function Body:

I would like to suggest a security enhancement for the _propose function. Currently, the _proposalId is not included in the root_merklehash. This might leave room for potential replay attacks.

To mitigate this risk, I propose that the _proposalId be included in the root_merklehash. This change would ensure that each proposal is uniquely identified in the root_merklehash, thus providing additional security against replay attacks.

    function _propose(
        address from,
        uint duration,
        bytes32[] memory params,
        bool isFull
    ) internal returns (uint) {
        uint _proposalId = curProposalId++;
        //TODO:
        bytes32 root = MerkleProof.processProof(params, bytes32(0));

Thank you for considering this proposal. I believe this enhancement would significantly improve the security of the system.