Overflow Excessive claims could overwhelm storage _userWithdrawals mapping

[code423n4]

Lines of code

https://github.com/code-423n4/2023-04-eigenlayer/blob/5e4872358cd2bda1936c29f460ece2308af4def6/src/contracts/pods/DelayedWithdrawalRouter.sol#L157

Vulnerability details

Impact

By submitting an excessive number of claims through a compromised user, an attacker could theoretically overwhelm the storage used for mapping users to their delayed withdrawals. If critical data is overwritten, the contract would be rendered unusable until significant cleanup is performed.

Proof of Concept

Here is a proof of concept for manipulating delayed withdrawal claims by overwhelming storage:

The attacker gains control/influence over a user with access to claimDelayedWithdrawals and holdings that will yield many delayed withdrawals. This is done through the same means as the previous PoC (social engineering, bribery, etc).

Once control of the user is established, the attacker instructs them to call claimDelayedWithdrawals as rapidly as possible to claim as many delayed withdrawals as they are able to in quick succession.

The attacker continues exploiting their control over the user to repeatedly call claimDelayedWithdrawals, claim more withdrawals, and repeat until the storage used by the _userWithdrawals mapping is near its limit.

At this point, any new delayed withdrawal claims will start overwriting critical data in storage as there is no space left. The attacker then halts claims just short of corrupting data needed to actually send funds (recipient addresses, amounts, etc).

With the _userWithdrawals mapping nearly full of meaningless data, the contract is effectively locked up and unusable. No new deposits or claims can be processed due to lack of storage, and the attacker has effectively carried out a denial of service attack.

Once the attack is fulfilled, the attacker may choose to restart limited claims just to further exacerbate issues, or sever their control/influence over the compromised user now that maximum damage has been done. Either way, exploiting a user's access to overwhelm critical storage represents a successful attack scenario according to this PoC.

The end result is essentially a lockup of the contract's functionality through a logic-based denial of service attack. No funds are directly stolen in this PoC but the contract is left unusable until significant storage cleanup is performed.

Tools Used

The only tools involved are the malicious access gained over a user to repeatedly call claimDelayedWithdrawals. No sophisticated technical skills or tools would be required beyond standard social engineering/compromise techniques.

Recommended Mitigation Steps

Here are some recommendations to help mitigate the risk of storage overflow from excessive delayed withdrawal claims:

• Enforce account limits - Apply absolute limits to the maximum number of delayed withdrawal claims that can be made by a single user/account. Even with control, an attacker cannot exceed fixed limits.

• Increase storage allowance - If legitimate use cases require a large number of withdrawals, increase the storage allocated to the _userWithdrawals mapping. But do so conservatively, as this also increases the "blast radius" of any successful attack.

• Educate users - Warn users against sharing access or signing blind requests to claim more withdrawals than needed. An informed user is less prone to manipulation.

• Monitor activity - Monitor user accounts for spikes in delayed withdrawal claims activity and cap at a rate that ensures storage cannot possibly be maxed out, even if compromised.

• Limit access - Grant only the access absolutely necessary for legitimate use cases. Narrower access reduces what can be directly exploited, even if somehow compromised.

• Consider alternative designs - Alternative designs may avoid or mitigate this particular storage overflow risk. Explore options with smaller "attack surfaces" and fewer critical data concentrations.

• Limit account lifetimes - Consider mechanisms to automatically deactivate user accounts/access after periods of inactivity. This reduces available attack vectors over time if no legitimate use continues.

• Require re-authentication - Require user re-authentication (e.g. sign-in) for sensitive actions like claiming withdrawals. This introduces more points of failure for any ongoing attack and can terminate it if authenticity is lost.

Assessed type

Under/Overflow

[0xSorryNotSorry]

Spam.

[c4-pre-sort]

0xSorryNotSorry marked the issue as low quality report

[c4-judge]

GalloDaSballo marked the issue as unsatisfactory: Invalid