Re-org attack in some functions

[c4-bot-9]

Lines of code

https://github.com/code-423n4/2024-05-arbitrum-foundation/blob/6f861c85b281a29f04daacfe17a2099d7dad5f8f/src/assertionStakingPool/AssertionStakingPoolCreator.sol#L15-L22 https://github.com/code-423n4/2024-05-arbitrum-foundation/blob/6f861c85b281a29f04daacfe17a2099d7dad5f8f/src/assertionStakingPool/EdgeStakingPoolCreator.sol#L15-L22 https://github.com/code-423n4/2024-05-arbitrum-foundation/blob/6f861c85b281a29f04daacfe17a2099d7dad5f8f/src/rollup/BOLDUpgradeAction.sol#L516-L517

Vulnerability details

Some functions employ the use of a fixed salt value which allows resulting deployment addresses to become predictable and non-unique. Also, contract deployments conducted using the new keyword are susceptible to re-orgs, which can reorder or remove transactions.

Impact

• Deploying contracts with fixed salt values, particularly 0, increases the risk of address collisions and lack of uniqueness across deployments -Re-organization (re-org) vulnerabilities can lead to temporary chain divergences where transactions, including contract deployments, may be reordered or removed.

Proof of Concept

1. https://github.com/code-423n4/2024-05-arbitrum-foundation/blob/6f861c85b281a29f04daacfe17a2099d7dad5f8f/src/assertionStakingPool/AssertionStakingPoolCreator.sol#L15-L22
2. https://github.com/code-423n4/2024-05-arbitrum-foundation/blob/6f861c85b281a29f04daacfe17a2099d7dad5f8f/src/assertionStakingPool/EdgeStakingPoolCreator.sol#L15-L22
3. https://github.com/code-423n4/2024-05-arbitrum-foundation/blob/6f861c85b281a29f04daacfe17a2099d7dad5f8f/src/rollup/BOLDUpgradeAction.sol#L516-L517

Tools Used

Manual review

Recommended Mitigation Steps

Deploy such contracts via create2 with salt that includes msg.sender

Assessed type

Other