Normal behavior: During registration, the contract assigns the user a random slice size and stores it in users_claimed_amount
. Later, the user claims exactly that assigned amount from the resource account balance.
Issue: get_random_slice
derives randomness from timestamp::now_microseconds()
and reduces it with % 401
. Block producers can influence timestamps within consensus bounds, making outcomes predictable and biasable. The #[randomness]
attribute is present but no aptos_framework::randomness
API is used.
Likelihood:
Validators routinely set/adjust block timestamps within allowed skew during registration transactions; the monotonic, low-entropy input produces predictable residues in % 401
.
Impact:
Fairness is undermined: attackers bias for larger slices.
The `get_random_slice` function should only be called by the owner via the `register_pizza_lover` function. Also, the `owner` is trusted and will not choose a specific time for a new user to register. Therefore, I disagree with the claim of most reports in this group that an attacker can manipulate the random number of pizza slices. But I agree with the root cause of the reports in this group, that the random distribution is not completely random.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.