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

Incorrect deposit check when canceling user's foreclosure in function deposit #170

Closed
code423n4 opened this issue Jun 17, 2021 · 3 comments
Labels
1 (Low Risk) bug Something isn't working duplicate This issue or pull request already exists

Comments

@code423n4
Copy link
Contributor

Handle

shw

Vulnerability details

Impact

In the function deposit of RCTreasury, a user's foreclosure can be canceled even if he did not deposit enough tokens for the minimum rent.

Proof of Concept

During a deposit, at line 303, the user's deposit is increased by the deposit amount. However, at line 309, when checking whether to cancel the user's foreclosure, user[_user].deposit + _amount is compared to the minimum rent. That is, the deposit amount is counted twice. Suppose that the minimum rent is x, then the foreclosed user only needs to deposit x/2 + 1 to cancel his foreclosure.

Referenced code:
RCTreasury.sol#L303
RCTreasury.sol#L309

Recommended Mitigation Steps

Change user[_user].deposit + _amount to user[_user].deposit at line 309.

@code423n4 code423n4 added 2 (Med Risk) bug Something isn't working labels Jun 17, 2021
code423n4 added a commit that referenced this issue Jun 17, 2021
@Splidge Splidge added the duplicate This issue or pull request already exists label Jun 17, 2021
@Splidge
Copy link
Collaborator

Splidge commented Jun 17, 2021

Duplicate of #26

@Splidge Splidge marked this as a duplicate of #26 Jun 17, 2021
@Splidge Splidge closed this as completed Jun 17, 2021
@dmvt
Copy link
Collaborator

dmvt commented Jul 9, 2021

I generally think the impact of this on the rest of the system is minimal. It results in a slight advantage to the user in foreclosure, but does not cause a loss or granting of additional funds. To take advantage of this exploit, the user would also need to be highly skilled at reading source code to find the exploit in the first place. Even if they took the time to do this, the effect would not be permanent. I'm aligned with the view expressed in #26 and #37 that this is low severity.

@dmvt
Copy link
Collaborator

dmvt commented Jul 11, 2021

duplicate of #108

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1 (Low Risk) bug Something isn't working duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

3 participants