code423n4 commented 1 year ago

Lines of code

https://github.com/code-423n4/2023-07-axelar/blob/9048517392e03720a0cd32d5b79db84f5e5f7c8e/contracts/cgp/governance/AxelarServiceGovernance.sol#L42-L62

Vulnerability details

Impact

The current implementation of the AxelarServiceGovernance contract relies solely on the Keccak256 algorithm to generate proposal hashes, using only the target contract's address, encoded function call data, and the native token transfer value as components. This poses a potential vulnerability as the uniqueness of each proposal hash is not guaranteed, making the system susceptible to replay attacks. An attacker could easily duplicate or resubmit previous proposals, leading to unintended or malicious actions being executed.

To mitigate the replay attack vulnerability, it is recommended to include the nonce and chain ID as additional components in the Keccak256 hash calculation for generating proposal hashes. By doing so, each proposal will have a unique cryptographic value, preventing replay attacks and ensuring the uniqueness of each proposal.

Proof of Concept

To demonstrate the fix for the vulnerability and the mitigation of replay attacks, the contract should be updated to include the nonce and chain ID as additional components when computing the proposal hash. This way, each proposal submission will receive a unique cryptographic value that increments with each new submission, ensuring hash distinctiveness. Furthermore, including the chain ID ensures that proposals are specific to their intended blockchain network, making them invalid on different chains even if other components are replicated.

Update the Proposal Hash Calculation Function:

function _calculateProposalHash( address target, bytes calldata callData, uint256 nativeValue ) internal view returns (bytes32) { // Include nonce and chain ID as additional components bytes32 proposalHash = keccak256( abi.encodePacked(target, callData, nativeValue, nonce, chainId) ); return proposalHash; }

Increment Nonce for Each New Proposal.

Tools Used

VSC

Recommended Mitigation Steps

To mitigate the vulnerability caused by breaking the uniqueness invariant when generating proposal hashes, the following steps should be taken:

Update the proposal hash computation: Modify the _processCommand function to include the nonce and chain ID as additional components when generating the proposal hash.

Retrieve the nonce and chain ID from helper functions within the contract, and use them as the fourth and fifth components, respectively, in the Keccak256 hash calculation.

By implementing the nonce and chain ID components, replay attacks will be prevented, ensuring the uniqueness of each proposal and enhancing the overall security of the governance system.