Zero address Pauser assignment

[code423n4]

Lines of code

https://github.com/code-423n4/2023-04-eigenlayer/blob/5e4872358cd2bda1936c29f460ece2308af4def6/src/contracts/permissions/PauserRegistry.sol#L41

Vulnerability details

Impact

By exploiting the unpauser role's access to call _setPauser with any address input, an attacker could permanently disable a core functionality (pausing/unpausing the token) by assigning a zero address as the pauser. No pauser would mean no ability to freeze transactions even in an emergency, manipulating the token's utility and potentially its value.

Proof of Concept

Here is a proof of concept for assigning a zero address as the pauser:

The attacker determines the address that currently holds the unpauser role, as only that role is authorized to call _setPauser. They do so by reviewing transaction logs or other on-chain mechanisms to find the unpauser's current address.

Once the unpauser address is known, the attacker begins social engineering attacks to manipulate that specific account holder into taking some malicious action. The goal is gaining indirect control over the unpauser role, even if just temporarily.

If the social engineering attack succeeds in compromising the unpauser, the attacker can then call _setPauser(0x0) to assign a zero address as the pauser.

With no valid pauser address assigned, any attempt to pause or unpause token transfers will fail, effectively breaking that core functionality. Legitimate token holders will be unable to freeze the token in an emergency scenario.

The damage from assigning a zero address pauser is irreversible without deploying a contract update. At this point, the attacker's PoC has successfully exploited the lack of input validation in _setPauser to disable crucial pauser controls and manipulate the token.

For maximum impact, the attacker can conduct these manipulations during periods of high token activity or volatility to maximize losses and confusion from the failed pause/unpause attempts.

The key steps are social engineering to gain control over the unpauser role, then exploiting that access to call _setPauser with a zero address input, breaking the pauser functionality permanently. While unpausing would still be possible if needed by assigning a valid pauser address in the future, the vulnerability would remain, and this PoC demonstrates how it could be maliciously leveraged.

Tools Used

The tools primarily consist of social engineering techniques like phishing emails, manipulated trust relationships and malicious messages targeted at gaining control of the unpauser account. No special technical skills are required beyond standard compromise techniques.

Recommended Mitigation Steps## Tools Used

Here are recommendations to help prevent and mitigate zero address pauser assignment:

• Implement input validation - Add checks to validate and sanitize input passed to _setPauser to ensure a non-zero address before assignment. This would prevent the vulnerability scenario directly.

• Require multi-signature for unpauser changes - Requiring more approvals than a single account for modifying sensitive roles like unpauser makes compromise substantially more difficult. Multi-sig would add the necessary checks.

• Closely monitor unpauser account - Regularly review logs/activity for the unpauser account and be highly suspicious of any unknown logins or access which could indicate an ongoing compromise attempt. Monitor for signs of suspicious behavior targeting the pauser address.

• Limit unpauser access - Only grant the minimum access needed for legitimate use cases. A limited unpauser scope would reduce the impact of compromise even if its access was somehow seized.

• Educate unpauser account owner - Provide training on best practices to avoid manipulation/social engineering targeting sensitive accounts with administrative access like the unpauser. A well-informed and vigilant account holder is less prone to exploitation.

• Consider alternative designs - Evaluate options that distribute sensitive controls rather than concentring them in a single role. For example, use on-chain governance voting on changes rather than hierarchical roles with broad power. Separate controls have fewer single points of failure.

• Monitor and limit high-risk periods - Closely review security, logs, and accounts during times of high volatility or activity which could be targeted to maximize losses from any successful manipulation. Establish allowances that limit changes during riskier periods.

Assessed type

Invalid Validation

[0xSorryNotSorry]

Spam

[c4-pre-sort]

0xSorryNotSorry marked the issue as low quality report

[c4-judge]

GalloDaSballo marked the issue as unsatisfactory: Invalid