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

Hash approval not possible when contractor == subcontractor #86

Open
code423n4 opened this issue Aug 4, 2022 · 4 comments
Open

Hash approval not possible when contractor == subcontractor #86

code423n4 opened this issue Aug 4, 2022 · 4 comments
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") valid

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2022-08-rigor/blob/f2498c86dbd0e265f82ec76d9ec576442e896a87/contracts/Project.sol#L859

Vulnerability details

Impact & Proof Of Concept

When a contractor (let's say Bob) is also a subcontractor (which can be a valid scenario), it is not possible to use the hash approval feature for checkSignatureTask. The first call to checkSignatureValidity will already delete approvedHashes[address(Bob)][_hash], the second call therefore fails.

Note that the same situation would also be possible for builder == contractor, or builder == subcontractor, although those situations are probably less likely to occur.

Recommended Mitigation Steps

Delete the approval only when all checks are done.

@code423n4 code423n4 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working labels Aug 4, 2022
code423n4 added a commit that referenced this issue Aug 4, 2022
@itsmetechjay
Copy link

@parv3213 can you chime in on this one?

@parv3213 parv3213 added the sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") label Aug 19, 2022
@parv3213
Copy link
Collaborator

parv3213 commented Sep 1, 2022

@jack-the-pug I think this issue is different from #239 or #86.

@jack-the-pug
Copy link
Collaborator

@jack-the-pug I think this issue is different from #239 or #86.

Do you mean #64? I think this is a dup of #239, but not a dup of #64.

@parv3213
Copy link
Collaborator

parv3213 commented Sep 4, 2022

Hmm. Apologies, you are right. This issue is a dupe of #239.

@parv3213 parv3213 reopened this Sep 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") valid
Projects
None yet
Development

No branches or pull requests

4 participants