search

sherlock-audit / 2024-02-optimism-2024-judging

6 stars 4 forks source link

Trust - M - The safety mechanism of the DelayedWETH contract can be bypassed #193

Closed sherlock-admin4 closed 6 months ago

sherlock-admin4 commented 7 months ago

Trust

medium

M - The safety mechanism of the DelayedWETH contract can be bypassed

Summary

A malicious user can frontrun directly the admin's call of hold() function in DelayedWETH. They can reset back the approval to zero, so that the admin cannot actually confiscate their funds.

Vulnerability Detail

DelayedWETH has several safety mechanisms in place to prevent malicious actors from cashing out illicit profits. The hold() function allows the owner to set arbitrary approval:

function hold(address _guy, uint256 _wad) external {
    require(msg.sender == owner(), "DelayedWETH: not owner");
    allowance[_guy][msg.sender] = _wad;
    emit Approval(_guy, msg.sender, _wad);
}

The function only sets a custom approval for the admin. However it doesn't make use of that approval. A malicious guy who is supposed to lose access to their funds, can frontrun the call with approve(admin, 0). At this point, the admin can no longer confiscate their funds.

The only resolution for the admin is to bundle together the hold() and transferFrom() calls, but until they figure out how to do that, additional time was wasted, making it likely that the freezing time will have passed and the malicious user can call withdraw() to cash out their profits into ETH, which is unsanctionable.

Impact

Bypass of a key security mechanism of the DelayedWETH contract

Code Snippet

function hold(address _guy, uint256 _wad) external {
    require(msg.sender == owner(), "DelayedWETH: not owner");
    allowance[_guy][msg.sender] = _wad;
    emit Approval(_guy, msg.sender, _wad);
}

Tool used

Manual Review

Recommendation

The hold() function should either:

guhu95 commented 5 months ago

you have to understand what is written

What am I misunderstanding in what was written?

The scenarios initially presented as such were shown to be invalid due to the FDG being the sole holder of DelayedWETH, and the only scenarios presented since then were: https://github.com/sherlock-audit/2024-02-optimism-2024-judging/issues/193#issuecomment-2094982627 and https://github.com/sherlock-audit/2024-02-optimism-2024-judging/issues/193#issuecomment-2101623114, and both depend on a future integration.

If there's a scenario that does not involve a hypothetical future integration, can you please share it?

zobront commented 5 months ago

@trust1995 Ok, sounds like we are close. For clarity I'm going to copy & paste what I wrote and edit based on your feedback. If you agree with this, then will turn off notifications for this damn issue lol.

Do you agree with those facts?

My personal assessment of that is that this is saying (a) a future integration for DelayedWETH, (b) would have the potential to create a rug vector that users might not notice, and opens the possibility that (c) if DelayedWETH admins acted slowly and didn't understand what was happening, would have the potential to cause problems.

But that last line is my personal opinion. I think most important is agreement on the facts above, and then it's up to judges from there.

trust1995 commented 5 months ago

The scenarios initially presented as such were shown to be invalid due to the FDG being the sole holder of DelayedWETH, and the only scenarios presented since then were: #193 (comment) and #193 (comment), and both depend on a future integration.

By that logic, if an in-scope Chainlink contract can be made to provide malicious feeds, it would be out of scope because it "relies on future integration with the contract". Though it should clearly be marked as high. You need to apply common sense and differentiate between:

The issue falls into category (1) per the discussions above.

Do you agree with those facts?

I already objected with this which was not changed:

As pointed earlier, they may have as little as 1 block to come up with a fix, if they assume they have 7 days to hold & confiscate the funds without interruption. So disagree with sufficiently long.

Regarding your opinion:

My personal assessment of that is that this is saying (a) a future integration for DelayedWETH, (b) would have the potential to create a rug vector that users might not notice, and opens the possibility that (c) if DelayedWETH admins acted slowly and didn't understand what was happening, would have the potential to cause problems.

This statement is heavily skewed, but my objections to each section were already stated so will not repeat again and let judges decide.

Evert0x commented 5 months ago

It's clear now that the issue depends on the integration from a future contract. And the assumption is made that DelayedWETH is going to be a contract that expects future integrations but there is no contextual evidence for this. Even if there was, there is no issue in the in-scope contracts.

There is no mention that FDG is the only possible user, but It's also not explicitly stated that it is built for other people to integrate with.

The protocol team also provided the following context.

We would not fix the issue because DelayedWETH was only meant to be used with the FDG and its security properties are specifically designed around its use with the FDG.

I will reject the escalation and keep the issue as is

Evert0x commented 5 months ago

Result: Invalid Has Duplicates

sherlock-admin2 commented 5 months ago

Escalations have been resolved successfully!

Escalation status: