s0x0mtee - Attacker can add a `reply` even if not registered and can also reply to an `invalid` target by setting the `targetContract` parameter to a mallicious contract where the checks for `targetContract` will be validated. #264
Attacker can add a reply even if not registered and can also reply to an invalid target by setting the targetContract parameter to a mallicious contract where the checks for targetContract will be validated.
Summary
The lack of validation of targetContract parameter in addReply() means the user can pass the address of any contract address to it and this address is then passed down to _checkIfTargetExistsAndAllowed(targetContract, targetId) which is called in addReply()
Now provided the contract passed into targetContract follows the ITargetStatus interface it will execute successfully, this means the attacker is in complete control of the logic and what the return values will be and can set both return values to true for any targetId including 0 and numbers > replyCount which would cause lots of problems since the EthosDescussion contract's core logic heavily relies on no reply having Id of 0 or greater than replyCount.
These replys will not belong to any of the ethos contracts(profile/discussion/attestation) but to the mallicious contract which has been set, hence there will replys with to place for them, and unnecessarily increasing the replyCount and causing so many breaks in the contract's logic
Root Cause
The target contract argument in addReply isn't checked to make sure it's part of Ethos contracts.
s0x0mtee
Medium
Attacker can add a
reply
even if not registered and can also reply to aninvalid
target by setting thetargetContract
parameter to a mallicious contract where the checks fortargetContract
will be validated.Summary
The lack of validation of
targetContract
parameter inaddReply()
means the user can pass the address of any contract address to it and this address is then passed down to_checkIfTargetExistsAndAllowed(targetContract, targetId)
which is called inaddReply()
Now provided the contract passed into
targetContract
follows theITargetStatus
interface it will execute successfully, this means the attacker is in complete control of the logic and what the return values will be and can set both return values to true for anytargetId
including 0 and numbers > replyCount which would cause lots of problems since the EthosDescussion contract's core logic heavily relies on no reply having Id of0
or greater thanreplyCount
. Thesereplys
will not belong to any of the ethos contracts(profile/discussion/attestation) but to the mallicious contract which has been set, hence there willreplys
with to place for them, and unnecessarily increasing the replyCount and causing so many breaks in the contract's logicRoot Cause
addReply
isn't checked to make sure it's part of Ethos contracts.Internal pre-conditions
isTargetThisContract
needs to be false https://github.com/sherlock-audit/2024-10-ethos-network/blob/main/ethos/packages/contracts/contracts/EthosDiscussion.sol#L115External pre-conditions
targetContract
needs to follow theITargetStatus
interfaceAttack Path
targetContract
instead of one of the ethos contractsaddReply()
Impact
PoC
//malicious contract
//test
This test passes
Mitigation
addReply()
such as