Open feezybabee opened 10 months ago
Nit: both cases are overflows.
As for the vulnerability, I don't think it's possible with current snarkVM/OS code, but it's something that may need to be fixed with future users of the snarkVM libraries in mind.
https://hackerone.com/reports/2258963
Summary:
The nonnative_params::find_parameters() function accepts two parameters that are involved in further arithmetic operations:
base_field_prime_length
andtarget_field_prime_bit_length
. Both parameters can be considered controllable as they are thrown to the PoseidonSponge API:PoseidonSponge::compress_elements() -> get_params() -> find_parameters()
PoseidonSponge::get_limbs_representations_from_big_integer() -> get_params() -> find_parameters()
Where
base_field_prime_length
will be equal toF::size_in_bits()
andtarget_field_prime_bit_length
will be equal toTargetField::size_in_bits()
.Consider the following code line: https://github.com/AleoHQ/snarkVM/blob/c620cc4a89bcd81e9de07e827886a2a57e4375e6/algorithms/src/traits/algebraic_sponge.rs#L177. Since
base_field_prime_length
value is not checked to be more then 13,usize
underflow may occur.At the same way since
target_field_prime_bit_length
value is not checked,usize
overflow may occur on the following code line: https://github.com/AleoHQ/snarkVM/blob/c620cc4a89bcd81e9de07e827886a2a57e4375e6/algorithms/src/traits/algebraic_sponge.rs#L184.And we can see many such cases further down the code, since the function does not contain any checks at all.
Proof-of-Concept (PoC)
To check these vulnerabilities, I have prepared the following tests:
Results are shown below:
Impact
In a release build, this vulnerability will not cause panic and will produce false results on specifically crafted
TargetField
andPrimeField
.