Several solidity/random-beacon contracts use try-catch blocks as part of their business logic. However, the EVM has a call stack depth limit equal to 1024. A third-party contract can leverage this limitation and force the try-catch-ed calls to revert unconditionally, by using recursion and letting those calls be executed at depth 1025. In such a case, the control flow is passed to the catch clauses which may lead to undesired side effects. Possibly affected contracts/libraries are:
RandomBeacon
BeaconDkg
This issue is about inspecting the existing try-catch blocks and fixing them in case they are prone to the aforementioned problem. A possible fix is requiring that the caller is an EOA using the following check:
require(msg.sender == tx.origin, "Not EOA");
Existing deployments of the solidity/random-beacon contracts have to be upgraded once the random beacon becomes operable and starts creating groups.
Several
solidity/random-beacon
contracts usetry-catch
blocks as part of their business logic. However, the EVM has a call stack depth limit equal to 1024. A third-party contract can leverage this limitation and force thetry-catch
-ed calls to revert unconditionally, by using recursion and letting those calls be executed at depth 1025. In such a case, the control flow is passed to thecatch
clauses which may lead to undesired side effects. Possibly affected contracts/libraries are:RandomBeacon
BeaconDkg
This issue is about inspecting the existing
try-catch
blocks and fixing them in case they are prone to the aforementioned problem. A possible fix is requiring that the caller is an EOA using the following check:Existing deployments of the
solidity/random-beacon
contracts have to be upgraded once the random beacon becomes operable and starts creating groups.Note: A similar problem was already fixed in the
WalletRegistry
contract living in thesolidity/ecdsa
package: https://github.com/keep-network/keep-core/pull/3756