Late Navy Fly
High
Lack of a nonce combined with not saving the value of r, s, and v, will allow signature replay attacks
Lack of protection against signature replay will cause loss of funds for users as the attacker will reuse the signature
In Lib.sol:95 the values of r, s, and v are not save (yes I know that a library cannot store a variable), and in Lib.sol:130 a nonce is not used in the hashed message, from what I did understand from this code is that there is a nonce but it is not included in the message hash because the unsignedTxRaw skips it.
https://github.com/sherlock-audit/2024-10-gamma-rewarder/blob/main/GammaRewarder/contracts/brevis/lib/Lib.sol#L95-L98 https://github.com/sherlock-audit/2024-10-gamma-rewarder/blob/main/GammaRewarder/contracts/brevis/lib/Lib.sol#L105-L127 https://github.com/sherlock-audit/2024-10-gamma-rewarder/blob/main/GammaRewarder/contracts/brevis/lib/Lib.sol#L130
Since this smart contract is a library, there is no guarantee that there will be a protection in all the uses that will avoid signature replay. It can be implemented outside the library, but the protection should be in the library itself to avoid cases where the smart contract does a protection but in a not correct way.
No response
No response
No response
The users will have their funds drained by the attacker if he calls decodeTx multiple times, and the attacker gains that amount. The information in TxInfo makes me understand that there will be a transaction with value that the signature will validate, because of that I assume that the attacker be able to repeat the signature draining funds.
No response
Use a nonce in the message hash. Alternatively, another possible way to solve would be to also return the encodePacked values of v, r, s for the purpose of saving it in a mapping to see if it was already used.