Closed c4-bot-6 closed 4 months ago
minhquanym marked the issue as primary issue
minhquanym marked the issue as sufficient quality report
I think this is a valid report, although the severity is not high. Fixed in this PR: https://github.com/taikoxyz/taiko-mono/pull/16606/files
dantaik (sponsor) confirmed
@dantaik - can you clarify why you don't believe this to be impactful? It does seem M is warranted as the function of the protocol is affected, no?
2 — Med: Assets not at direct risk, but the function of the protocol or its availability could be impacted, or leak value with a hypothetical attack path with stated assumptions, but external requirements.
0xean marked the issue as satisfactory
@dantaik - see https://github.com/code-423n4/2024-03-taiko-findings/issues/205 for perhaps a better impact statement
0xean marked the issue as selected for report
Hi @0xean, I think this issue should be of QA-severity, here's why:
If there is no check present, the guardians sending another proof could be considered as incorrect input supplied by a trusted role. This falls under QA since trusted roles are providing incorrect parameters. Also to note, the guardians are selected by the DAO and Security council as Dan mentioned in his BCR video linked in the README.
Overall, I think the check is more of a sanity check than a major issue to the protocol's functionality.
Would like to hear your opinion on this in case I'm misjudging.
Thank you!
Hi @0xean, I think this issue should be of QA-severity, here's why:
If there is no check present, the guardians sending another proof could be considered as incorrect input supplied by a trusted role. This falls under QA since trusted roles are providing incorrect parameters. Also to note, the guardians are selected by the DAO and Security council as Dan mentioned in his BCR video linked in the README.
Overall, I think the check is more of a sanity check than a major issue to the protocol's functionality.
Would like to hear your opinion on this in case I'm misjudging.
Thank you!
See #205 -
The issue arises from the fact that the approved message doesn't include the _proof. It means that the last approving guardian can provide any desired value in the _proof. The data from the _proof is used to determine whether it is necessary to return the liveness bond to the assigned prover or not:
To me the above represents a privilege escalation or if nothing malicious an issue that could affect the functioning of the protocol. Based on that I think M is correct.
0xean marked issue #205 as primary and marked this issue as a duplicate of 205
0xean marked the issue as not selected for report
Lines of code
https://github.com/code-423n4/2024-03-taiko/blob/main/packages/protocol/contracts/L1/provers/GuardianProver.sol#L33
Vulnerability details
Summary
The natspec for GuardianProver::approve() says the following on L33 but the "sent the same proof" clause is never really checked inside the function:
Description & Impact
approved_ = true
is(9 + 1) / 2 = 5
.proofX
while callingapprove()
.proofY
.proofX
. Since thehash
on L46 is calculated without involving the proof, L47 will returntrue
at the 5th guardian's call even though Guardian4 had usedproofY
.proveBlock()
is called with_proof
equallingproofX
._proof
Guradian5 uses while callingapprove()
will be used to callproveBlock()
on L51, irrespective of whatever the previous guardians passed.Thus the guardian proof is approved even when in reality the required votes have not been achieved.
Tools Used
Manual review
Recommended Mitigation Steps
Compare the
_proof.data
to make sure approval for the same proof is being provided by all the guardians.Assessed type
Invalid Validation