142 Protocol security record

In the contract `BEP20`, the role `burnAuth` has authority over the functions shown in the diagram below. Any compromise to the `burnAuth` account may allow the hacker to take advantage of this authority and set burn authorization address, decrease LP tokens for a pair.  In the contract `BEP20`, the role `eAuth` has authority over the functions shown in the diagram below. Any compromise to the `eAuth` account may allow the hacker to take advantage of this authority and set buy and buy fee enable, set sell and sell fee enable flags, set the eAuth address, set the transaction enable flag.  In the contract `BEP20`, the role `emergency` has authority over the functions shown in the diagram below. Any compromise to the `emergency` account may allow the hacker to take advantage of this authority and set the emergency address.  In the contract `BEP20`, the role `feeAuth` has authority over the functions shown in the diagram below. Any compromise to the `feeAuth` account may allow the hacker to take advantage of this authority and set the fee authorization address, set market pair status, set the buy fee, set the sell fee.  In the contract `BEP20`, the role `whaAuth` has authority over the functions shown in the diagram below. Any compromise to the `whaAuth` account may allow the hacker to take advantage of this authority and remove addresses from fee whitelist, remove addresses from whitelist, set the `whaAuth` address, add fee whitelist accounts, and add accounts to whitelist. Whitelisted address can by pass the check of buy/sell enabled flag.  In the contract `FOMOToken`, the role `emergency` has authority over the functions shown in the diagram below. Any compromise to the `emergency` account may allow the hacker to take advantage of this authority and take out any specified tokens in an emergency.  In the contract `Ownable`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and renounce ownership or transfer contract ownership. 

**In the `FomoToken` contract, both the `owner` and `burnAuth` have the ability to arbitrarily burn the fomo token balance of any LP pair address without proper restrictions or safeguards.** ```solidity function decreaseLPToken(address pair, uint256 amount) external { require(burnAuth == msg.sender || owner() == msg.sender, "auth error"); _basicTransfer(pair, Dead, amount); _burn(pair, Dead, amount); IPair(pair).sync(); } ``` If either the `owner` or `burnAuth` accounts are compromised, a malicious actor could exploit this authority to manipulate the balance of trading pairs. This functionality also introduces significant centralization concerns. Burning tokens directly from a liquidity pool without any restrictions or checks can harm LP providers by reducing their asset holdings, impairing the value of the liquidity pool, and destabilizing the token's market.

All of the `FOMO` tokens are sent to the contract deployer on deployment. This is a centralization risk because the deployer can distribute tokens without obtaining the consensus of the community. Any compromise to the deployer address may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project. ```solidity constructor() BEP20Detailed("FOMO", "FOMO", 18) { _totalSupply = 100_000_000_000 * (10 ** 18); _balances[_msgSender()] = _totalSupply; emit Transfer(address(0), _msgSender(), _totalSupply); } ```

The typical token burn logic involves transferring tokens to the 'Dead' or zero address, while simultaneously reducing the total token supply by the same amount. This ensures that the total circulating supply accurately reflects the tokens held by non-burn addresses. However, in the current `FomoToken` contract, the `transfer()` and `transferFrom()` functions do not enforce a check on the recipient parameter. As a result, it is possible to transfer tokens directly to the 'Dead' or zero address without appropriately updating the `totalBurn` or `_totalSupply` values. In addition, the `_totalSupply` value is not updated in the `_burn()` function. ```solidity function _burn(address sender, address recipient, uint amount) private { if (recipient == address(0) || recipient == Dead) { totalBurn = totalBurn.add(amount); // _totalSupply = _totalSupply.sub(amount); @Audit: update of total supple commented out emit Burn(sender, Dead, amount); } } ``` This leads to a mismatch between the contract's internal state and the actual circulating supply. Specifically, the `totalBurn` and `_totalSupply` variables will reflect inaccurate values than the true circulating supply, which can mislead token holders and affect financial calculations relying on the token supply.

There are no upper boundaries for function `setBuyFee` and `setSellFee` which is used to update buy/sell fee rate on token transfer. It is possible to set the total fee rate up to any arbitrary amount. ```solidity function setBuyFee(uint256 val) external { require(feeAuth == msg.sender || owner() == msg.sender, "auth error"); _buyFee = val; } function setSellFee(uint256 val) external { require(feeAuth == msg.sender || owner() == msg.sender, "auth error"); _sellFee = val; } ```

The contract contains a hardcoded address `0x8835d34cD7191837f95263E2FCd563593B6FEf9B` for the `feeTo` addresss, which is responsible for collecting transaction fees. Hardcoding addresses into the contract can introduce several risks, such as lack of flexibility to change the address during the contract's lifecycle and potential security concerns if the address becomes compromised. ```solidity address public feeTo = 0x8835d34cD7191837f95263E2FCd563593B6FEf9B; ```

In several parts of the `FomoToken` contract, addresses are assigned to critical roles such as `emergency`, `burnAuth`, `eAuth`, `whaAuth`, and `feeAuth` without being validated to ensure they are not the zero address. Assigning the zero address to these critical roles could lead to significant issues, such as permanent loss of control over key functionalities of the contract. For example, granting the zero address authority in any role could make it impossible to revoke or change certain permissions, leading to an irreversible loss of contract control. ```solidity function setWHA(address _addr) external { require(whaAuth == msg.sender, "auth error"); whaAuth = _addr; } function setEAuth(address _addr) external { require(eAuth == msg.sender, "auth error"); eAuth = _addr; } function setFeeAuth(address _addr) external { require(feeAuth == msg.sender, "auth error"); feeAuth = _addr; } function setBurnAuth(address _addr) external { require(burnAuth == msg.sender, "auth error"); burnAuth = _addr; } function setEmergencyEn(address _addr) external { require(emergency == msg.sender, "auth error"); emergency = _addr; } ```

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Solidity version >=0.8.0 includes checked arithmetic operations and underflow/overflow by default, making SafeMath redundant. ```solidity=99 using SafeMath for uint; ```

The return values of the `transfer()` and `transferFrom()` calls in the smart contract are not checked. Some ERC-20 tokens' transfer functions return no values, while others return a bool value, they should be handled with care. If a function returns `false` instead of reverting upon failure, an unchecked failed transfer could be mistakenly considered successful in the contract. ```solidity function takeOutTokenInCase(address _token, uint256 _amount, address _to) external { require(emergency == msg.sender || owner() == msg.sender, "auth error"); IBEP20(_token).transfer(_to, _amount); //@Audit: return value not checked here. } ```