Open hats-bug-reporter[bot] opened 2 months ago
In order to challenge a request, this request should be resolving. In order to be resolving, this request should have the requester side funded. Therefore, when a challenge is created, the funded side prior to the call will be the requester (and not "none") and due to this line after the call, the side funded of "round 0" will become None.
Moreover, a new round will be created. And the rule function will check the last round (so round 1 in your example, not round 0).
The rule 0 serves to contain the deposits of the requester and challenger. The other rounds serves to contain the appeal deposits. At no point the side funded of round 0 can impact a rule. The rule function just checks that we are not in a case of having only one side provide the appeal deposit.
Hey @clesaege, thank you for your reply.
In order to challenge a request, this request should be resolving.
I agree with this.
In order to be resolving, this request should have the requester side funded.
I agree with this, as well.
However, your third point is wrong. In advanceState()
function, the following require(request.challenges[0].rounds[0].sideFunded == Party.Requester);
is using challengeId
which equals to 0. In challengeRequest
before calling _contribute()
the challengeId
is incremented by 1. This will result in _contribute
using the round of the same humanity ID, request ID, round ID, but different challenge ID. Which means that indeed round.sideFunded
is equal Party.None
and will become Party.Challenger
.
In challengeRequest before calling _contribute() the challengeId is incremented by 1
This isn't true, it is a postfix ++
so the value assigned to challengeId
is the value before the incrementation.
Github username: -- Twitter username: johny37GR Submission hash (on-chain): 0xcdaddb03b584a667a1358a2ac865e62eb6b010f1adb3390fac8e2df5ef8f3789 Severity: high
Description: Description\ Any humanity claim request can be denied at the challenging period if a malicious actor challenges the request, and fully funds it. Also, if the reason is
IdentityTheft
orSybilAttack
, the malicious actor can also delete the voucher's huminity ids.The reason is, the
_contribute
atchallengeRequest
. i.e.require(_contribute(_humanityId, _requestId, challengeId, 0, Party.Challenger, arbitrationCost));
Which is called with
_humanityId
,_requestId
,challengeId
andParty.Challenger
.The
_contribute
mutate around
that is new, due tochallengeId
being unique.If the
msg.value
is at least therequired.amount
it will write inround.sideFunded
theParty.Challenger
.When the arbitrator calls
rule()
, no matter his_ruling
theresultRuling
will get overwritten byParty.Challenger
because theround.sideFunded
will always beParty.Challenger
.See
Round storage round = challenge.rounds[challenge.lastRoundId];
Attack Scenario\
Legitimate user calls
claimHumanity
to start the process of claiming a humanity.He passes the vouching system since it's a legitimate request.
A malicious actor calls
challengeRequest
on his claim request, with reasonIdentityTheft
orSybilAttack
and fully funded, that will result inround.sideFunded = Party.Challenger
The arbitrator calls
rule()
in favor of the requester, but theRound storage round = challenge.rounds[challenge.lastRoundId];
is the round that was mutated atchallengeRequest() -> _contribute()
and as a result,round.sideFunder equal Party.Challenger
. TheultimateChallenger
will be set.Malicious actor calls
processVouches
to delete all voucher's humanity ids.Attachments
ProofOfHumanity.sol@L709-725
ProofOfHumanity.sol@L1406-1429
ProofOfHumanity.sol@L1440-1475
ProofOfHumanity.sol@L1005-1071
ProofOfHumanity.sol@L1315-1377