Closed sherlock-admin4 closed 3 months ago
Is this only valid for ERC20 fees, or for ETH fees? If ERC20 then this shouldn't be in scope, but if it is valid for ETH as well then it is in scope.
Quoted from here https://github.com/sherlock-audit/2024-04-titles-judging/issues/69
"Only ETH is supported per the contest Q&A. Won't fix."
Hence this issue should be invalidated
Escalate
Out of scope, as the comments above imply.
Escalate
Out of scope, as the comments above imply.
You've created a valid escalation!
To remove the escalation from consideration: Delete your comment.
You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.
In discord, the protocol sponsor clearly stated:
pqseags — 24/04/2024 21:55 I wanted to clear up a common question - while the readme states that any ERC20 token is supported, actually only ETH >is fully supported in all parts of the protocol.
Therefore this is clearly invalid as it related to ERC20
Per the contest Readme of Future Integrations " Should potential issues, like broken assumptions about function behavior, be reported if they could pose risks in future integrations, even if they might not be an issue in the context of the scope? If yes, can you elaborate on properties/invariants that should hold? Yes. " This should be valid
Per the contest Readme of Future Integrations " Should potential issues, like broken assumptions about function behavior, be reported if they could pose risks in future integrations, even if they might not be an issue in the context of the scope? If yes, can you elaborate on properties/invariants that should hold? Yes. " This should be valid
In this specific scenario this does not apply, as the sponsor clearly stated that ERC20 token will not be utilised (as shown in my previous comment showing their direct message in discord). This is like saying that if sponsor says no fee-on-transfer tokens are going to be used, but still all fee-on-transfer issues should still be validated because technically they could still be used in the future.
If sponsor clearly states certain tokens types are not going to be used then they are out of scope and invalid.
Per the contest Readme of Future Integrations " Should potential issues, like broken assumptions about function behavior, be reported if they could pose risks in future integrations, even if they might not be an issue in the context of the scope? If yes, can you elaborate on properties/invariants that should hold? Yes. " This should be valid
In this specific scenario this does not apply, as the sponsor clearly stated that ERC20 token will not be utilised (as shown in my previous comment showing their direct message in discord). This is like saying that if sponsor says no fee-on-transfer tokens are going to be used, but still all fee-on-transfer issues should still be validated because technically they could still be used in the future.
If sponsor clearly states certain tokens types are not going to be used then they are out of scope and invalid.
You may be right but there are clear indications in the protocol for the use of ERC20s. For example all the TransferFrom's and address of tokens. Per the message you quoted the sponsor said only ETH is fully supported but there are mechanisms for handling ERC20s. The example you gave does not apply as there won't be any intended mechanism for handling feeOnTransfer Tokens indicating any future integration. And also per the source of truth hierarchy, contest Readme is the highest source of Truth (hence the future integrations part). Again I might be wrong here with the reasoning, let Hash decide.
If the results are valid, the template will be retained for future report submissions
From "Evert | Sherlock" on discord:
@herethe README has been updated. The exact diff is here https://github.com/sherlock-audit/2024-04-titles/commit/d7f60952df22da00b772db5d3a8272a988546089
Only issues related to native ETH will be accepted. Any issues related to ERC20 tokens will not be accepted.
As mentioned by the Watsons above, the contracts are using only Native ETH, hence, issues about ERC20s should be invalidated. Planning to accept the escalation and invalidate the issue.
@WangSecurity
and leave the issue as it is
you mean invalidate right?
@0xjuaan yes, thank you for notifying
Result: Invalid Has Duplicates
The protocol team fixed this issue in the following PRs/commits: https://github.com/titlesnyc/wallflower-contract-v2/pull/1
threadmodeling
high
TitlesCore._publish()
can be DOSd by consuming the user's allowance by frontrunningFeeManager.collectCreationFee()
Summary
When using an ERC20 for fees, the
PUBLISHER_ROLE
's allowance given toFeeManager
or the one of the user callingcreateEdition()
can be freely consumed throughFeeManager.collectCreationFee()
. This will move funds to theFeeManager
'sprotocolFeeReceiver
and DOS theTitlesCore._publish()
function (which is the main functionality on theTitlesCore
contract).Vulnerability Detail
In the
TitlesCore._publish()
function,FeeManager.collectCreationFee()
is called:FeeManager.collectCreationFee()
isn't permissioned or access-controlled, therefore it can be called by anyone:As we can see above, if there's a
fee.amount
to pay, the receiver is fetched from storage but thefeePayer_
depends on the (malicious) user's input.The
_route
function is basically a transfer that can either occur with native Ether or with an ERC20 token:Given that, here, the
from
parameter is controlled by the malicious user's input, it means that the frontrunning attack will transferfee.amount
offee.asset
fromvictim
toprotocolFeeReceiver
.While the amount isn't user controlled: multiple calls to
collectCreationFee()
can be made to either drain the victim's set allowance or funds (if max approval was given), whichever gives in first.The funds will probably be recoverable due
protocolFeeReceiver
being probably trusted to send them back, but draining the allowance will make any subsequent calls toTitlesCore._publish()
to revert, at only the cost of gas calls for the attacker, effectively DOSing the publish functionality onTitlesCore
Impact
While DOS attacks vary in severity, this one is easy and cheap for the attacker. Also, DOSing the
PUBLISHER_ROLE
and theTitlesCore._publish()
will additionally move their funds around. Hence, this is submitted as a High Severity bugCode Snippet
Tool used
Manual Review
Recommendation
Seeing a
transferFrom
function withfrom
being something else thanmsg.sender
will often result in such a bug. The flow of funds needs to be changed so thatFeeManager
's functions become permissioned or that approval is given and reset in the same transaction.