Funds can become locked in the contract if a very big nonce is used
Proof of Concept
When submitting a logicCall, a batchTransfer or an updateValset a nonce has to be submitted. The functions checks if the nonce is bigger than the last one but it can be arbitrarily bigger. If the new nonce is set to max(uint) then transactions will become impossible since no other nonce can be bigger. If this happens by mistake funds will be locked inside the contract.
My suggestion is to add a maximum step in nonce for example with 100 oldNonce<NewNonce<oldNonce+100.
In this way, nonces are still flexible but can't get too big in a single transaction.
V-Staykov
commented
2 years ago
Lines of code
https://github.com/code-423n4/2022-05-cudos/blob/de39cf3cd1f1e1cf211819b06d4acf6a043acda0/solidity/contracts/Gravity.sol#L289 https://github.com/code-423n4/2022-05-cudos/blob/de39cf3cd1f1e1cf211819b06d4acf6a043acda0/solidity/contracts/Gravity.sol#L494 https://github.com/code-423n4/2022-05-cudos/blob/de39cf3cd1f1e1cf211819b06d4acf6a043acda0/solidity/contracts/Gravity.sol#L385
Vulnerability details
Impact
Funds can become locked in the contract if a very big nonce is used
Proof of Concept
When submitting a logicCall, a batchTransfer or an updateValset a nonce has to be submitted. The functions checks if the nonce is bigger than the last one but it can be arbitrarily bigger. If the new nonce is set to max(uint) then transactions will become impossible since no other nonce can be bigger. If this happens by mistake funds will be locked inside the contract.
My suggestion is to add a maximum step in nonce for example with 100 oldNonce<NewNonce<oldNonce+100. In this way, nonces are still flexible but can't get too big in a single transaction.