Update Allocate.s.sol

[Odhiambo526]

1. Access Control: There are no access control mechanisms in place to restrict who can execute the run() function in both contracts. Anyone can call these functions and perform the allocation of tokens. To rectify this vulnerability, you can implement an access control mechanism that restricts who can execute the run() function in both contracts. For example, you can add a modifier that checks whether the caller of the function is the owner of the contract.
2. In the ProvisionWeth contract, the transfer() function is called on the weth contract, sending wethAmount tokens to recipientAddr. This can be a potential vulnerability if recipientAddr is an attacker's address. Additionally, payable(recipientAddr).transfer(1 ether) sends 1 ether to recipientAddr, which could be exploited by an attacker to drain the contract's ether balance. To fix this vulnerability, it is recommended to verify that recipientAddr is a trusted address before transferring tokens to it or sending ether. Additionally, the use of transfer() should be avoided in favor of call.value() to prevent reentrancy attacks.
3. Reentrancy: There is no protection against reentrancy attacks in the run() function of the ProvisionWeth contract. An attacker could potentially call the transfer() function repeatedly before the previous call completes, leading to a reentrancy attack. To rectify this vulnerability, you can implement a reentrancy guard by using the nonReentrant modifier provided by OpenZeppelin.
4. Integer Overflow/Underflow: The wethAmount variable in the Allocate contract is calculated by dividing eigenTotalSupply by (numStaker + numDis + 50). If numStaker + numDis + 50 is zero, it will cause an integer division by zero error. Moreover, if eigenTotalSupply is very large, this division could lead to an integer overflow error, resulting in an incorrect allocation of tokens. Integer Overflow/Underflow: To rectify this vulnerability, you can add a check to ensure that the denominator of the division in the Allocate contract is not zero, and use the SafeMath library provided by OpenZeppelin to avoid integer overflow/underflow errors.
5. Gas Limit Issues: The allocate() function in the Allocator contract may run out of gas if the number of recipients to allocate tokens to is too large. This could potentially result in an incomplete allocation, leading to a loss of tokens. To rectify this vulnerability, you can consider batching the allocation of tokens into smaller groups to avoid running out of gas. You can also use the GasToken library provided by OpenZeppelin to reduce the gas cost of token transfers.
6. Lack of Input Validation: The stdJson.readAddress function used in the code to read addresses from the JSON file does not perform input validation on the addresses being read, which could lead to unexpected results if the addresses are not valid. Therefore, it would be good practice to perform input validation explicitly before using any input data to ensure that it is safe and within expected parameters.

[ryanjsfx2424]

Did a bot submit this? Allocate.s.sol is a script used for deployment logic before running tests. So the ACL/reentrancy issues shouldn't be a problem here.

Also, SafeMath is obselete as of solidity 0.8.0 and allocate.s.sol requires 0.8.12