`LM_PC_Bounties_v1`: Verifier and Claimant can collude to steal all bounties

[hats-bug-reporter[bot]]

Github username: @0xfuje Twitter username: 0xfuje Submission hash (on-chain): 0x4406e1f858eeeca455d65a078cb1705f1ea398ac61a52567e611e0ccf573d11a Severity: medium

Description:

Impact

Loss of orchestrator system funds

Description

The verifier and claimant can collude to steal all valid bounties made by BOUNTY_ISSUER_ROLE. I believe the problem is that a single address with the VERIFIER_ROLE is not sufficient to validate this flow of funds.

Proof of Concept

1. Bounty issuer adds a bounty with a reward of 20_000 USDC
2. Instead of the true contributors Claimant adds his own and verifier's address and split amount via addClaim()
3. Verifier verifies that the malicious claim is correct (because he benefits from it) and splits the bounty with claimant via verifyClaim()

Recommendation

Consider to have one of the alternative solutions for VERIFIER_ROLE:

1. Add multiple verifiers so it's far less likely that a malicious collusion will happen.
2. Add functionality so the BOUNTY_ISSUER_ROLE should always check if the bounty is correct before verifyClaim().
3. Remove the VERIFIER_ROLE and enforce onlyOrchestratorAdmin on the access control of verifyClaim() since that's the highest form of access control in the system.

[PlamenTSV]

Per the sponsor's take on the matter with the trustworthyness of the module roles: If the Claimer can provide false claims, that is OOS since he is trusted not to do so. But if he can bypass important checks, put in place to limit his ability, it should be valid since it is not part of his intended functionality Your ability showcases how if the 2 roles turn malicious they can game the contract, but they do not use any functionality that they should not have, they use their trustfully granted ability to manage the contract's funds. Thus I think OOS.