Submitted by Kalogerone
https://github.com/code-423n4/2024-04-panoptic/blob/main/contracts/PanopticFactory.sol#L237
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/0a25c1940ca220686588c4af3ec526f725fe2582/contracts/proxy/Clones.sol#L53
(NOTE: This report is very highly inspired from this past valid report. Necessary changes have been made to suit the Panoptic Protocol.)
The attack consists of two parts: Finding a collision, and actually draining the lending pool. We describe both here:
Note that in PanopticFactory::deployNewPool, CREATE2 salt is user-supplied which is then passed to Clones::cloneDeterministic:
The address collision an attacker will need to find are:
Both sets of addresses can be brute-force searched because:
An attacker can find any single address collision between (1) and (2) with high probability of success using the following meet-in-the-middle technique, a classic brute-force-based attack in cryptography:
The feasibility, as well as detailed technique and hardware requirements of finding a collision, are sufficiently described in multiple references:
The hashrate of the BTC network has reached 6.5 x 10^20 hashes per second as of time of writing, taking only just 31 minutes to achieve 2^80 hashes. A fraction of this computing power will still easily find a collision in a reasonably short timeline.
Even given EIP-3607 which disables an EOA if a contract is already deployed on top, we show that its still possible to drain the Panoptic Pool entirely given a contract collision.
Assuming the attacker has already found an address collision against an undeployed Panoptic Pool, lets say 0xCOLLIDED. The steps for complete draining of the Panoptic Pool are as follow:
First tx:
Post Dencun hardfork, selfdestruct is still possible if the contract was created in the same transaction. The only catch is that all 3 of these steps must be done in one tx.
The attacker now has complete control of any funds sent to 0xCOLLIDED.
Second tx:
The attacker has stolen all funds from the Panoptic Pool.
Address collision can cause all tokens of a Panoptic Pool to be drain.
While we cannot provide an actual hash collision due to infrastructural constraints, we are able to provide a coded PoC to prove the following two properties of the EVM that would enable this attack:
Here is the PoC, as well as detailed steps to recreate it:
The provided PoC has been tested on Remix IDE, on the Remix VM - Mainnet fork environment, as well as testing locally on the Holesky testnet fork, which as of time of writing, has been upgraded with the Dencun hardfork.
Remix IDE
dyedm1 (Panoptic) acknowledged and commented:
Picodes (judge) commented:
