Platform: Code4rena
Start Date: 02/08/2023
Pot Size: $42,000 USDC
Total HM: 13
Participants: 45
Period: 5 days
Judge: hickuphh3
Total Solo HM: 5
Id: 271
League: ETH
Rank: 13/45
Findings: 2
Award: $565.66
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: Aymen0909
Also found by: 0xStalin, 0xbepresent, Arz, D_Auditor, Jorgect, T1MOH, bin2chen, dirk_y, josephdara, ptsanev, rvierdiiev, seerether, shirochan, trachev
89.6296 USDC - $89.63
https://github.com/GenerationSoftware/pt-v5-draw-auction/blob/f1c6d14a1772d6609de1870f8713fb79977d51c1/src/RngRelayAuction.sol#L131-L176 https://github.com/GenerationSoftware/pt-v5-draw-auction/blob/f1c6d14a1772d6609de1870f8713fb79977d51c1/src/RngRelayAuction.sol#L79
There is no check made to make sure the transaction is coming from the _rngAuctionRelayer
address, which could lead to stealing rewards and possible emptying of prize pool reserves by crafting the function parameters.
Even though it is intended for bots to use, all of the function are public https://github.com/GenerationSoftware/pt-v5-draw-auction/blob/f1c6d14a1772d6609de1870f8713fb79977d51c1/src/RngRelayAuction.sol#L131-L137 By monitoring the mempool, a malicious actor can craft a certain set of parameters and just copy the sequence id he saw in the successful RNG request.
Manual Review
Add a simple require check to make sure that the msg.sender
is the _rngAuctionRelayer
.
Invalid Validation
#0 - c4-pre-sort
2023-08-08T01:11:13Z
raymondfam marked the issue as low quality report
#1 - raymondfam
2023-08-08T01:11:40Z
This function deals with random numbers that had already been generated.
#2 - c4-pre-sort
2023-08-08T02:31:29Z
raymondfam marked the issue as remove high or low quality report
#3 - c4-pre-sort
2023-08-08T02:31:39Z
raymondfam marked the issue as duplicate of #82
#4 - c4-judge
2023-08-14T02:45:08Z
HickupHH3 marked the issue as satisfactory
🌟 Selected for report: MohammedRizwan
Also found by: MohammedRizwan, nadin, ptsanev
476.0281 USDC - $476.03
After a brief discussion with one of the sponsors, we have come to the conclusion that there is a protocol risk in case of a chain re-org for the LiquidationPairFactory.sol
. The idea of the Vaults the protocol offers is that each vault would be linked to a single LPair. LPairs can be deployed by anybody via the factory and an owner of a vault may choose to switch his LPair due to certain parameters being more favorable for his vault. In the scenario he decides to create his own LPair a re-org might lead to him providing the wrong pair address, which if left unnoticed can lead to fund losses for him and his users, certain uncompatibilities with his vault, etc. The malicious LPair could potentially have arbitrary function bodies, since there is also no internal check to make sure they have been factory deployed.
https://polygonscan.com/blocks_forked As of the time of the report, there are common forks of 4-5 blocks, spiking up to 20 blocks every few hours.
Manual Review
Simply use the create2
opcode and encode the many parameters needed to deploy a LPair to ensure uniqueness, not forgetting the salt and msg.sender
to avoid front-running
Other
#0 - c4-pre-sort
2023-08-07T23:47:10Z
raymondfam marked the issue as duplicate of #169
#1 - c4-judge
2023-08-12T08:58:29Z
HickupHH3 marked the issue as satisfactory
#2 - c4-judge
2023-08-15T03:02:14Z
HickupHH3 changed the severity to QA (Quality Assurance)
#3 - c4-judge
2023-08-15T03:03:01Z
HickupHH3 marked the issue as grade-c
#4 - c4-judge
2023-08-17T14:50:07Z
This previously downgraded issue has been upgraded by HickupHH3
#5 - thebrittfactor
2023-08-17T16:40:00Z
For transparency, the judge requested to remove the unsatisfactory label.