Github username: @https://github.com/betharavikiranSubmission hash (on-chain): 0x964bb3423fcbbcd0655920b62f37c89309337b77a6b887d373825dab6db72858
Severity: medium
Description:Description\
SaleState for presale starts from NOT_ACTIVE and transit to OVER state.
Below is the sequential flow of SaleState transitions.
NOT_ACTIVE => PRESEED => SEED => OVER
It does not make sense that after the SaleState is OVER, it could flow back into any of the preceeding states. This holds true for every state.
The reponsibility to ensure this sequence should be coded and smart contract should adhere to it. But, instead it has been assumed as the responsibility of the Owner account.
The code should enforce the transition rules,while the entitlement to execute can still be delegated to the owner.
Attack Scenario\
The attack scenario is that the owner with entitlements to update the SaleState has the ability to faciliate the minting of tokens at price 10 instead of 13 for some of the transaction of choice.
This can be done if the owner front runs the transaction to faciliate this benefit to an account at discretion.
Attachments
Proof of Concept (PoC) File
Refer to functions in the SeedPresaleCvg.sol
a) Declared Enum
enum SaleState {
NOT_ACTIVE,
PRESEED,
SEED,
OVER
}
b) setSaleState function
The function allows for transitions to any state without restriction.
function setSaleState(SaleState _saleState) external onlyOwner {
saleState = _saleState;
}
Revised Code File (Optional)
a) initialize the saleState in the constructor as below
saleState = SaleState.NOT_ACTIVE;
b) update the setSaleState function as below.
function setSaleState(SaleState _saleState) external onlyOwner {
require(saleState==SaleState.OVER);
if(_saleState == SaleState.PRESEED){
require(saleState==SaleState.NOT_ACTIVE);
}
else if (_saleState == SaleState.SEED){
require(saleState==SaleState.PRESEED);
}
else if (_saleState == SaleState.OVER){
require(saleState==SaleState.SEED);
}
saleState = _saleState;
}
Github username: @https://github.com/betharavikiran Submission hash (on-chain): 0x964bb3423fcbbcd0655920b62f37c89309337b77a6b887d373825dab6db72858 Severity: medium
Description: Description\ SaleState for presale starts from NOT_ACTIVE and transit to OVER state.
Below is the sequential flow of SaleState transitions.
NOT_ACTIVE => PRESEED => SEED => OVER
It does not make sense that after the SaleState is OVER, it could flow back into any of the preceeding states. This holds true for every state.
The reponsibility to ensure this sequence should be coded and smart contract should adhere to it. But, instead it has been assumed as the responsibility of the Owner account.
The code should enforce the transition rules,while the entitlement to execute can still be delegated to the owner.
Attack Scenario\ The attack scenario is that the owner with entitlements to update the SaleState has the ability to faciliate the minting of tokens at price 10 instead of 13 for some of the transaction of choice.
This can be done if the owner front runs the transaction to faciliate this benefit to an account at discretion.
Attachments
a) Declared Enum enum SaleState { NOT_ACTIVE, PRESEED, SEED, OVER }
b) setSaleState function The function allows for transitions to any state without restriction.
function setSaleState(SaleState _saleState) external onlyOwner { saleState = _saleState; }
saleState = SaleState.NOT_ACTIVE;
b) update the setSaleState function as below.
Files: