Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Users can withdraw in the same block (if the delay is zero) #42

Closed
code423n4 opened this issue Mar 18, 2022 · 2 comments
Closed

Users can withdraw in the same block (if the delay is zero) #42

code423n4 opened this issue Mar 18, 2022 · 2 comments
Labels
bug Something isn't working duplicate This issue or pull request already exists QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2022-03-prepo/blob/f63584133a0329781609e3f14c3004c1ca293e71/contracts/core/Collateral.sol#L144-L146
https://github.com/code-423n4/2022-03-prepo/blob/f63584133a0329781609e3f14c3004c1ca293e71/contracts/core/Collateral.sol#L128-L131

Vulnerability details

Impact

If the withdraw delay is 0 (which represent no expiration, because otherwise the withdrawal request will expire the moment it was created), the protection of withdrawing only in the next block ("Withdrawals must be requested in a prior block via initiateWithdrawal(uint256 amount). The number of blocks until a request expires is settable by the vault owner(). This is mainly for mitigating the feasibility of a flash loan attack.") doesn't work, because this check is in the _processDelayedWithdrawal function which is called only if the delay is not 0.

That bug opens the system to flashloan attacks, assuming that the withdraw delay is 0.

Tools Used

VS Code and Remix

Recommended Mitigation Steps

A possible fix will be to require the condition of the block numbers also if the withdraw delay is zero.

@code423n4 code423n4 added 3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working labels Mar 18, 2022
code423n4 added a commit that referenced this issue Mar 18, 2022
@ramenforbreakfast
Copy link
Collaborator

ramenforbreakfast commented Mar 22, 2022

duplicate of #36

@ramenforbreakfast ramenforbreakfast added the duplicate This issue or pull request already exists label Mar 22, 2022
@gzeoneth
Copy link
Member

gzeoneth commented Apr 3, 2022

Not an issue if the delay is specifically set to 0, but agree that it is inconsistant with the doc "Withdrawals must be requested in a prior block". Downgrading to Low/QA. Closing in favor of warden's QA report #40

@gzeoneth gzeoneth added QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax and removed 3 (High Risk) Assets can be stolen/lost/compromised directly labels Apr 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working duplicate This issue or pull request already exists QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax
Projects
None yet
Development

No branches or pull requests

4 participants