Open sherlock-admin2 opened 5 months ago
Believe #41 and #237 to not be duplicates based on different fix and code logic involved for (refunding/decrypting/settling mechanisms)
The fix isn't the same because we need to remove a loop from the refundBid function. The settle fix involves refactoring to allow a multi-txn process or decreasing the gas cost of it. Not really a good way to remove the loop from settle
The protocol team fixed this issue in the following PRs/commits: https://github.com/Axis-Fi/moonraker/pull/145
The protocol team fixed this issue in the following PRs/commits: Axis-Fi/moonraker#145
Fixed Now the index of the bid to be refunded is passed avoiding the iteration of the entire list.
The Lead Senior Watson signed off on the fix.
0xR360
medium
Attacker can forbid users to get refunded if sends enough bids on the EMPAM module
Summary
When an auction starts an attacker can send enough encrypted bids to make future users that bid unable to be refunded.
Vulnerability Detail
An attacker can send valid bids with amounts equal to the minimum allowed amount for a bid. If enough bids are sent, users that bid after him won't be able to get refunded if they want to. Scenario:
Impact
Breaks the refund functionality. User won't be able to refund bid. Possible loss of funds.
Code Snippet
https://github.com/sherlock-audit/2024-03-axis-finance/blob/main/moonraker/src/modules/auctions/EMPAM.sol#L284-L305
Putting this test on the EMPA refund bid tests file can show how its performed.
Tool used
Manual Review
Recommendation
Instead of looping through each bidId, holding the index position of a non encrypted bid on a mapping should solve it. The mapping should be from bidId to its position in the array. When a bid is refunded, this position should also be changed for its replacement.