Closed tbfleming closed 4 years ago
In order to focus our efforts on issues that are currently creating difficulty for the community we are closing tickets that were created prior to the EOSIO 2.0 release. If you believe this issue is still relevant please feel free to reopen it or create a new one. Thank you for your continued support of EOSIO!
controller_impl::create_native_account
uses this to set an initial ABI on theeosio
account:https://github.com/EOSIO/eos/blob/1418543149b7caf8fc69a23621e3db7f3c6d18ad/libraries/chain/controller.cpp#L870
There are several problems with this approach which may lead to consensus issues. The foundational problem is that this ABI isn't a version-independent constant:
abi_def
and related structs. This happened with the ABI 1.0 to 1.1 upgrade.eosio_contract_abi.cpp
changes. There's no indication ineosio_contract_abi.cpp
of this danger. In fact, there's a TODO in that file which encourages future change:// TODO add ricardian contracts
By itself, this wouldn't create a consensus problem since ABIs aren't currently available to contracts. However:
Speaking of RAM charges: this code fails to charge RAM for the ABI. This creates an inconsistency in RAM billing.
We do not believe this issue causes production networks which run 1.7.x or 1.8.x to be vulnerable to attack:
abi_def
oreosio_contract_abi.cpp
has changed. 1.7.x and 1.8.x agree on the initial ABI.Mitigation:
eosio
's ABI or replace it with a smaller one. Replacing it with a larger ABI is ok.Potential fixes:
eosio
ABI should be forced to be a constant across time. This means replacing the runtime-computed value with a hard-coded binary value which matches what 1.7.x and 1.8.x currently produce. This doesn't prevent chains from replacing the ABI usingsetabi
. They should, however, still be mindful of the first mitigation above.