You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
Although the submission regards the same role the ratingSecrets.count counter is increased twice. Any further submissions, for a different role, are now going to break the taskWorkRatingCommitOpen by failing the check:
Thanks for the submission @jakub-wojciechowski . We acknowledge it's an issue and we'll get back to you later this week with an accurate determination of risk level. The issue here will be fixed and closed before that but it is still considered.
Thanks for the submission @jakub-wojciechowski !
We've actually found a further exploit of this by a malicious task worker. It consists of an empty rating secret being accepted first, then a valid rating of the manager accepted second. Both submitted by the worker who can then continue to reveal their valid rating and after 5 days finalize the task.
This effectively means the evaluator gets unfairly penalised reputation-wise for not rating on time while the worker gets the maximum rating and reputation. All task roles can claim their payouts.
Overall the likelihood is towards the low end of "Medium" in owasp terms as this is only exploitable by poorly performing task worker or evaluator with some level of technical knowledge (submitting an empty rating won't be possible through the dApp). The impact is "Low" as this only affects the worker and evaluator not earning the correct reputation and worker potentially getting paid when they shouldn't have been. Even though this can potentially affect multiple tasks across multiple colonies, the 5 day buffer period lowers the impact considerably.
OWASP: Low, but would like to reward you in the mid-range of the pay bracket at $1,200