function transferOrchestratorToken(address to, uint amount)
external
onlyOrchestrator
validAddress(to)
{
_transferOrchestratorToken(to, amount);
}
Notice that the modifier validAddress is implemented to prevent Orchestrator from sending token to address(0) or address(this).
However in the following function in FM_Rebasing_v1.sol::
function withdrawTo(address to, uint amount) external {
_withdraw(_msgSender(), to, amount);
}
The functions above is missing validAddress modifier. As a result, tokens can be mistakenly sent to address(0) or address(this) which will impact and shrink the DEPOSIT_CAP.
Attack Scenario\
tokens can be mistakenly sent to address(0) or address(this) which will impact and shrink the DEPOSIT_CAP.
Attachments
NA
Proof of Concept (PoC) File
Manual analysis
Revised Code File (Optional)
Consider adding the validAddress modifier to FM_Rebasing_v1.sol::withdrawTo function.
The withdraw is sending the collateral token and not the Elastic Token part, so should be invalid.
Also the DepositCap cant be changed because its constant
Github username: @erictee2802 Twitter username: 0xEricTee Submission hash (on-chain): 0x54752d303f63a65e2a551c70ddd2b5c1120a7040375db355ac7d5d912ed22f0f Severity: low
Description: Description\
In
FM_Rebasing_v1.sol::transferOrchestratorToken
:Notice that the modifier
validAddress
is implemented to preventOrchestrator
from sending token toaddress(0)
oraddress(this)
.However in the following function in
FM_Rebasing_v1.sol:
:The functions above is missing
validAddress
modifier. As a result, tokens can be mistakenly sent toaddress(0)
oraddress(this)
which will impact and shrink theDEPOSIT_CAP
.Attack Scenario\
tokens can be mistakenly sent to
address(0)
oraddress(this)
which will impact and shrink theDEPOSIT_CAP
.Attachments
NA
Manual analysis
validAddress
modifier toFM_Rebasing_v1.sol::withdrawTo
function.