EthMultiVault.sol - atom creation gas grief

[hats-bug-reporter[bot]]

Github username: @PlamenTSV Twitter username: @p_tsanev Submission hash (on-chain): 0xb42854d1899d79a40075ff32b949b8ea8754673205c13887bae23575da398a54 Severity: medium

Description: Description\ Atoms are created throught the createAtom and batchCreateAtom functions, taking in the provided URI as the only parameter. The given URI is taken purely as it's own hashed value, which opens up front-running capabilities.

Attack Scenario\ Front-running an atom creation is probably known and would yield no economical gain for an attack doing so. However the batchCreateAtom can be weaponized via such front-running. Picture this: User A batch creates 100 atoms User B front-runs him and creates an atom with the same URI as the last atom of A User A's transaction reverts but he wastes has since he had to reach the last atom

Attachments

1. Proof of Concept (PoC) File

2. Revised Code File (Optional)

Recommendation\ Compute a unique hash combining the msg.sender and the URI

[PlamenTSV]

The case is the same for creating triples

[mihailo-maksa]

The reported issue of front-running in the createAtom and batchCreateAtom functions does not present a significant economic threat. Here's why:

1. No Economic Gain: The attacker would need to expend gas to front-run the transaction. This cost outweighs the potential benefit, as the attacker gains nothing of economic value by simply causing the original transaction to revert.
2. Gas Cost Consideration: Both the attacker and the original user incur gas costs. The attacker's expenditure to front-run and cause a revert does not yield any tangible benefit, making the attack economically unviable.
3. Mitigation of Actual Risk: While theoretically possible, the described attack does not provide a practical or profitable scenario for attackers. Implementing additional hash computations, such as combining msg.sender with the URI, would add complexity without addressing a substantial threat.

In conclusion, the issue, while technically valid, does not pose a realistic or economically beneficial threat. The proposed solution to combine msg.sender and URI hashes is noted, but we believe it is unnecessary given the lack of a viable economic incentive for attackers. For these reasons, report is considered invalid.

[PlamenTSV]

No economic gain is inquired, this is a griefing attack on the attacker's end. Gas expenditure to run the attack would not be higher than the gas consumption of the batch loop that we force to revert. The technicality and simplicity of the issue makes it a realistic scenario that can occur and the economical damage to the protocol itself can go beyond the reverted transaction and to the user's experience instead. Also yes, it is technically valid and qualifies via the given guidelines in points 1 and 4.

[PlamenTSV]

Less than a minute of searching, here's an example replica: https://github.com/hats-finance/Metrom-0xfdfc6d4ac5807d7460da20a3a1c0c84ef2b9c5a2/issues/2 I could go around and flood you with similar issues where unbound and overinflated gas expenditure is the highest concern, since we follow a guideline for what issues to report.

[PlamenTSV]

See ya at the dispute period