PermanentRestriction.allowL2Admin
is susceptible to meet in the middle attacks that allow an attacker to transfer admin control to an address that they control.
PermanentRestriction._validateMigrationToL2
validates that the migration happens to an expected admin contract, i.e. one that was deployed by the admin factory. To do so, it checks if the address exists in allowedL2Admins
, which can be populated by any user via allowL2Admin
by setting the appropriate parameters. The CREATE2 address is then derived based on these parameters:
It is not checked if this contract exists / was actually deployed by the factory. In theory, this is not necessary, as the contract has to be deployed by the factory by the derivation logic and the contracts can always get deployed later on.
However, as an address is only 160-bit long and the user here controls 3 * 256 bits that influence the derivation (which is more than enough, 80 bits would be sufficient for the attack outlined), a meet-in-the-middle attack can be used to get a collision with an attacker controlled address with high probability in a reasonable time / cost. To do so, the attacker would bruteforce a sufficient number of values (2^80) for one parameter (e.g. deploymentSalt
) while keeping the other one fixed. The resulting account addresses would be calculated and efficiently stored, e.g. in a Bloom filter. Then, the attacker would prepare an exploit contract and iterate over the deployment nonces / salts there until a collision is found. Then, the attacker would deploy their exploit contract and whitelist it for the migration by calling allowL2Admin
with the deploymentSalt
that results in the same address as their exploit contract. It would now be allowed for the migration and the attacker's exploit contract would be the admin after the migration.
Note that the attack may already feasible economically today if the stakes are high enough (which should be the case here, as millions / billions would be at stake). This will only get worse in the future. In 2021, Vitalik Buterin wrote:
Even without address space extension, collisions today take 2^80 time to compute, and that length of time is already within range of nation-state-level actors willing to spend huge amounts of resources. For reference, the Bitcoin network performs 2^80 SHA256 hashes once every two hours.
In 2023, Mysten Labs wrote:
The results of these efforts show that the cost of 160-bit hash collision attacks can be accomplished under certain assumptions and access to hardware for as little as just a few million dollars ($), making it a feasible attack vector even for individuals or less sophisticated actors.
Nowadays, there is even an EIP because of these concerns.
As explained above, an attacker can abuse this to become the admin of the chain after the migration.
Check that the contract was deployed by the factory, which can be done easily by storing the deployed addresses. Then, the discussed attack no longer works (as the deployment from the factory would fail if the address is already used).
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.