Recipient address is not appropriately validated or sanitized in the BaseFeeVault contract (loss of funds)

[code423n4]

Lines of code

https://github.com/ethereum-optimism/optimism/blob/382d38b7d45bcbf73cb5e1e3f28cbd45d24e8a59/packages/contracts-bedrock/contracts/L2/BaseFeeVault.sol#L19

Vulnerability details

Impact

If the recipient address is not properly validated, an attacker could supply a malicious address as the recipient. This could result in the accumulated fees being sent to an unintended or unauthorized party. It could lead to financial loss or disruption of the intended fee distribution mechanism.

Contract Vulnerability: A malicious recipient address could be a contract that is designed to exploit vulnerabilities in the BaseFeeVault contract or its parent contracts. This could result in unauthorized access to funds, manipulation of fee calculations, or disruption of the fee accumulation process.

Denial-of-Service (DoS) Attacks: If the recipient address is not sanitized, an attacker could provide an address that causes unexpected behavior or triggers expensive operations, leading to excessive gas consumption or contract execution failure. This could result in a denial-of-service attack, where the contract becomes unusable or incurs significant costs.

Inconsistent Fee Distribution: Without proper validation, the accumulated fees may not be correctly distributed or utilized as intended. This can lead to inconsistencies in fee allocation, potentially impacting the incentives or rewards associated with the fee distribution mechanism.

Reputation and Trust: If the contract fails to appropriately validate or sanitize the recipient address, it can erode user trust and damage the reputation of the contract or the platform it operates on. Users may be hesitant to engage with a contract that is susceptible to such vulnerabilities, resulting in reduced adoption and usage.

Proof of Concept

In this proof of concept, the proofOfConcept function demonstrates an attack scenario by passing a malicious address as the recipient during the contract deployment. The malicious address bypasses any validation or sanitation checks that should have been in place. The doSomething function is called to simulate an action that triggers the accumulation of fees. Finally, the getAccumulatedFees function is called to retrieve the accumulated fees, which would have been intended for the legitimate recipient. However, in this attack scenario, the fees are now controlled by the attacker, resulting in financial loss and compromise of the contract's functionality. Link: https://github.com/seerether/Stader/blob/143f97b3b1576a58d1642e607033f1826027cf53/Attackproof#L25-L69

Tools Used

Manual

Recommended Mitigation Steps

To mitigate potential attacks related to an improperly validated or sanitized recipient address, it is recommended to implement the following steps:

Validating Non-Zero Address: Add a validation check to ensure that the recipient address is not the zero address. This validation step helps prevent funds from being sent to an uninitialized or invalid address. This can be done using the require statement: Link: https://github.com/seerether/Stader/blob/a01570c144d7e05cfaac2238e3fb736f07d778f4/optimismmitigation#L23

Checking for Contract Address: Implement an internal function, _isContract, to determine if an address belongs to a contract. Use this function to check whether the recipient address is a contract address. If it is, reject the transaction to prevent potential manipulation or vulnerabilities associated with accumulating fees in a contract controlled by an attacker. Link: https://github.com/seerether/Stader/blob/a01570c144d7e05cfaac2238e3fb736f07d778f4/optimismmitigation#L32-L37

Inside the constructor, add the following requirement to ensure the recipient address is not a contract: Link: https://github.com/seerether/Stader/blob/a01570c144d7e05cfaac2238e3fb736f07d778f4/optimismmitigation#L24

By following these recommended mitigation steps, you enhance the security and integrity of the BaseFeeVault contract by ensuring that the recipient address is appropriately validated and sanitized, mitigating the risk of potential attacks.

Assessed type

Invalid Validation

[0xleastwood]

This is simple input validation. Would not happen in practice and if it did, it would be picked up on deployment.

[c4-judge]

0xleastwood marked the issue as unsatisfactory: Overinflated severity