Closed sherlock-admin closed 9 months ago
2 comment(s) were left on this issue during the judging contest.
PNS commented:
M-1 OZ Audit; Fillers generally estimate gas before execution and use private mempools like flashbots or mevblocker.
0xAadi commented:
Invalid: OOS, external DB is OOS, external can/can't have reactor validation before calling quote() or pushing result to db
In theory, that's true, but this issue is tightly connected to the way the server works. So, while it's possible to create an order with some arbitrary data, even with malicious reactor, and in theory such order can be executed, the server ensures validity of the order, which includes a check for a correct reactor address (because it doesn't really makes sense from server's perspective to accept orders, that are intended to be execute through unkown contracts).
HSP
high
Attacker can submit malicious order and user may lose funds interacting with it
Summary
GladiusOrderQuoter does not verify if the reactor in an order is valid, attacker can submit order with malicious reactor, user who interacts with this order may suffer a loss.
Vulnerability Detail
GladiusOrderQuoter is used on the off-chain side, and validates orders during their creation, before pushing them into database.
Market maker can send POST request to the API to submit an order, GladiusOrderQuoter will validate the order through the quoter, before accepting it.
To validate an order, quote(...) function is called, this function quotes the given order, returning the ResolvedOrder object which defines the current input and output token amounts required to satisfy it:
After the order is validated by GladiusOrderQuoter, it is pushed into database, and takers will see the order through API, which is similar to this:
And response looks like below:
The problem is GladiusOrderQuoter does not verify if the reactor in an order is valid, an attacker can submit an order with malicious reactor which may, for instance, do nothing but executing gas-consuming operations, the validation will still passed and user will suffer a loss.
Please see the test codes:
The malicious reactor contract may look like below:
Impact
There could be serious impacts to the protocol:
Order is submitted off-chain, attacker can submit a very high volume of orders with no cost, the front-end which most users rely on may be swamped with fake orders;
Orders validated by GladiusOrderQuoter are supposed to be trusted, traders who interact with the malicious orders will get nothing but wasting a lot of gas fees, however this is not their fault;
Things can be much worse given that trader may grant token allowance to the malicious reactor, as suggested in the doc, if that is the case, user's funds can be stolen:
Code Snippet
https://github.com/sherlock-audit/2024-02-rubicon-finance/blob/main/gladius-contracts-internal/src/lens/GladiusOrderQuoter.sol#L26-L40
Tool used
Manual Review
Recommendation
To fix the trust issue in GladiusOrderQuoter, please verify if the reactor in an order is valid during invalidation: