In addition to the security of funds, we would also like there to be focus on the sanctity of the data in the TitlesGraph and the permissioning around it (only the appropriate people/contracts can signal reference and acknowledgement of reference).
The contest's README stated that apart from the loss of assets, the protocol team would like there to be a focus on the sanctity of the data. Thus, any issues related to the sanctity of the data in the Graph would be considered a valid Medium issue in the context of this audit contest, as the Contest's README supersede Sherlock's judging rules per Sherlock's Hierarchy of truth.
Both acknowledgeEdge and unacknowledgeEdge functions rely on the same modifier (checkSignature) to verify the signature validity. Thus, the signature used for acknowledgment and deacknowledgment of an edge follows the same format and can be used interchangeably. However, this design creates an issue, as described next.
Assume that Bob wants to acknowledge an edge. Thus, Bob calls the acknowledgeEdge function with his signature $Sig_1$.
A malicious user can always front-run Bob, take his signature ($Sig_1$) and sent to the unacknowledgeEdge function instead. When the unacknowledgeEdge function is executed with $Sig_1$, the signature will be marked as used by the code _isUsed[keccak256(signature)] = true;.
When Bob's acknowledgeEdge transaction gets executed, it will revert because his signature ($Sig_1$) has already been used.
The malicious users can keep repeating as the chain's gas fees on L2 are cheap.
The same trick can also be used to block someone from deacknowledge an edge.
Consider using two different hash types for acknowledging or deacknowledging within the signature and use a different modifier for checking the signature. This will prevent malicious users from taking the signature intended for acknowledgeEdge and submitting it to unacknowledgeEdge, and vice versa.
With this design, if a creator creates a signature intended for acknowledgeEdge function, and a malicious user front-runs and copies the signature and submits it to acknowledgeEdge function, no harm is done as the malicious user is simply executing the task on behalf of the creator. The edge will still be acknowledged at the end.
xiaoming90
medium
Malicious users can block creators from acknowledging or deacknowledging an edge
Summary
Malicious users can block someone from acknowledging or deacknowledging an edge, affecting the sanctity of the data in the Graph.
Vulnerability Detail
Both
acknowledgeEdge
andunacknowledgeEdge
functions rely on the same modifier (checkSignature
) to verify the signature validity. Thus, the signature used for acknowledgment and deacknowledgment of an edge follows the same format and can be used interchangeably. However, this design creates an issue, as described next.Assume that Bob wants to acknowledge an edge. Thus, Bob calls the
acknowledgeEdge
function with his signature $Sig_1$.A malicious user can always front-run Bob, take his signature ($Sig_1$) and sent to the
unacknowledgeEdge
function instead. When theunacknowledgeEdge
function is executed with $Sig_1$, the signature will be marked as used by the code_isUsed[keccak256(signature)] = true;
.When Bob's
acknowledgeEdge
transaction gets executed, it will revert because his signature ($Sig_1$) has already been used.The malicious users can keep repeating as the chain's gas fees on L2 are cheap.
The same trick can also be used to block someone from deacknowledge an edge.
https://github.com/sherlock-audit/2024-04-titles/blob/main/wallflower-contract-v2/src/graph/TitlesGraph.sol#L118
https://github.com/sherlock-audit/2024-04-titles/blob/main/wallflower-contract-v2/src/graph/TitlesGraph.sol#L146
https://github.com/sherlock-audit/2024-04-titles/blob/main/wallflower-contract-v2/src/graph/TitlesGraph.sol#L40
Impact
Malicious users can block someone from acknowledging or deacknowledging an edge, affecting the sanctity of the data in the Graph.
Code Snippet
https://github.com/sherlock-audit/2024-04-titles/blob/main/wallflower-contract-v2/src/graph/TitlesGraph.sol#L118
https://github.com/sherlock-audit/2024-04-titles/blob/main/wallflower-contract-v2/src/graph/TitlesGraph.sol#L146
https://github.com/sherlock-audit/2024-04-titles/blob/main/wallflower-contract-v2/src/graph/TitlesGraph.sol#L40
Tool used
Manual Review
Recommendation
Consider using two different hash types for acknowledging or deacknowledging within the signature and use a different modifier for checking the signature. This will prevent malicious users from taking the signature intended for
acknowledgeEdge
and submitting it tounacknowledgeEdge
, and vice versa.With this design, if a creator creates a signature intended for
acknowledgeEdge
function, and a malicious user front-runs and copies the signature and submits it toacknowledgeEdge
function, no harm is done as the malicious user is simply executing the task on behalf of the creator. The edge will still be acknowledged at the end.