Platform: Code4rena
Start Date: 03/05/2022
Pot Size: $75,000 USDC
Total HM: 6
Participants: 55
Period: 7 days
Judge: Albert Chon
Total Solo HM: 2
Id: 116
League: COSMOS
Rank: 11/55
Findings: 3
Award: $1,251.36
🌟 Selected for report: 0
🚀 Solo Findings: 0
While the voting power of the current valset is checked when the checkValidatorSignatures function is called in updateValset, the power of the new valset is not.
This could cause some functions to not work since whenever checkValidatorSignatures is called with the new valset, the function would revert because the new valset would not have enough voting power.
The updateValset function is called with a _newValset that does not have enough voting power. The _currentValset is set to this _newValset on L337 by setting the last valset checkpoint to the new valset checkpoint.
When calling checkValidatorSignatures with the newly set _currentValset that now does not have enough voting power, the function reverts since cumulativePower <= _powerThreshold.
Affected functions:
Add a check for the voting power of the new valset in the updateValset function, similar to the power check in the constructor.
#0 - V-Staykov
2022-05-11T11:13:53Z
Duplicate of #123
The documentation describes the use of tokens other than CUDOS in the Gravity.sol contract; so it is assumed that the CUDOS token will not be the only supported token. The documentation also states that validators on the Tendermint chain will use the information in the emitted event for the sendToCosmos function to determine the amount of tokens to be minted on the Tendermint side.
For transfer-on-fee/deflationary tokens, where the final _amount emitted may not be the same as the _amount in, the emitted amount value in SendToCosmosEvent could be incorrect. This could result in a mismatch of the balance between the Ethereum side and the Tendermint side for the account.
Gravity.sol using the sendToCosmos function.Gravity.sol is less than _amount (eg. 90 tokens).sendToCosmos function emits the original amount (100 tokens).Gravity.sol.Check the balance of the Gravity contract before the transfer and again after the transfer in sendToCosmos. The emitted amount should be the difference of the 2 balances.
#0 - mlukanova
2022-05-10T14:49:32Z
Duplicate of #3
🌟 Selected for report: IllIllI
Also found by: 0x1337, 0x1f8b, 0xDjango, 0xkatana, AmitN, CertoraInc, Dravee, Funen, GermanKuber, GimelSec, Hawkeye, JC, MaratCerby, WatchPug, Waze, broccolirob, cccz, ch13fd357r0y3r, cryptphi, danb, defsec, delfin454000, dipp, dirk_y, ellahi, gzeon, hake, hubble, ilan, jah, jayjonah8, kebabsec, kirk-baird, m9800, orion, oyc_109, robee, shenwilly, simon135, sorrynotsorry
128.5517 USDC - $128.55
_powerThreshold value in the constructor of Gravity.solThe power threshold should at least be more than 0 otherwise any amount of validator signatures is enough.
Add a check in the constructor for the _powerThreshold just before the voting power check for the valset on L659.
If a malicious validator calls the the submitBatch function in Gravity.sol and sets _batchNonce to the max value for uint256 then submitBatch would become unusable for that particular token since the require condition on L385 cannot be passed.
The updateValset function may be affected in a similar way with its _newValset.valsetNonce.
Add a check that the _batchNonce and the _newValset.valsetNonce values are only a certain amount more than the last nonce value.
ValsetUpdatedEventThe documentation states that the _eventNonce value should not be emitted in the ValsetUpdatedEvent, however ValsetUpdatedEvent has an _eventNonce field and the updateValset emits the state_lastEventNonce value.
Remove the _eventNonce field from ValsetUpdatedEvent and from the emitted event in updateValset.