ENS contest - rajatbeladiya's results

Below issues seem to be duplicate of this issue https://github.com/code-423n4/2022-07-ens-findings/issues/38 https://github.com/code-423n4/2022-07-ens-findings/issues/283 https://github.com/code-423n4/2022-07-ens-findings/issues/285 https://github.com/code-423n4/2022-07-ens-findings/issues/14 https://github.com/code-423n4/2022-07-ens-findings/issues/18 https://github.com/code-423n4/2022-07-ens-findings/issues/36 https://github.com/code-423n4/2022-07-ens-findings/issues/65 https://github.com/code-423n4/2022-07-ens-findings/issues/106 https://github.com/code-423n4/2022-07-ens-findings/issues/112 https://github.com/code-423n4/2022-07-ens-findings/issues/129 https://github.com/code-423n4/2022-07-ens-findings/issues/93 https://github.com/code-423n4/2022-07-ens-findings/issues/140 https://github.com/code-423n4/2022-07-ens-findings/issues/151 https://github.com/code-423n4/2022-07-ens-findings/issues/160 https://github.com/code-423n4/2022-07-ens-findings/issues/167 https://github.com/code-423n4/2022-07-ens-findings/issues/194 https://github.com/code-423n4/2022-07-ens-findings/issues/196 https://github.com/code-423n4/2022-07-ens-findings/issues/203 https://github.com/code-423n4/2022-07-ens-findings/issues/226 https://github.com/code-423n4/2022-07-ens-findings/issues/229 https://github.com/code-423n4/2022-07-ens-findings/issues/22 https://github.com/code-423n4/2022-07-ens-findings/issues/152 https://github.com/code-423n4/2022-07-ens-findings/issues/142

Recommend reducing severity to QA

I'm downgrading this to Medium. There are external factors required to make this problem occur, but if it does the functionality of the protocol as a whole could be severely impacted.

It's unclear to me how this could be a significant issue. Anyone writing code to register names knows that any excess funds will be returned, and therefore that they need a fallback that consumes minimal gas. Any EVM change that increases the gas of fallback functions would be breaking for a great number of contracts beyond ENS.

It's unclear to me how this could be a significant issue.

The register functions will fail, consuming a good bit of gas along the way if this occurs. If this were not such a critical piece of functionality I would have considered it QA, but a failure here breaks the protocol.

Anyone writing code to register names knows that any excess funds will be returned, and therefore that they need a fallback that consumes minimal gas. Any EVM change that increases the gas of fallback functions would be breaking for a great number of contracts beyond ENS.

The fact that other contracts will break along with ENS does not invalidate the issue. This is a clearly documented problem that has been known for years (see ref links). There is no reason to introduce more critical contracts to the ecosystem that will fail in this scenario, particularly when it is so easy to avoid.

The register functions will fail, consuming a good bit of gas along the way if this occurs. If this were not such a critical piece of functionality I would have considered it QA, but a failure here breaks the protocol.

I think the implied API here is that any contract registering names with the controller must either send the right amount of ether, or have a fallback function that can accept ether. Changes to the consensus layer that invalidate that assumption for a given contract are out-of-scope for ENS.

Sending all remaining gas with the refund increases the threat surface by allowing possible reentrancy etc, which we haven't examined as a threat model here.