Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Consensus protocol upgrade to restrict authorization checking when sending actions to self #6705
EOSIO has a powerful permissions system that determines when authorizations (in the form of an account name and permission name pair) are allowed to be added to an action.
The general rules for action authorizations, which applies to all of the original actions in an input (or user-signed) transaction, are as follows:
These rules not only apply for all of the original actions in an input transaction, they also apply for many inline actions and actions in contract-generated deferred transactions. In that case however, the authorization context will be different.
For original actions in an input transaction, the authorization context includes the public keys corresponding to the signatures on the transaction as well a provided time delay set based on the
For inline actions, the authorization context includes the
For actions in a deferred transaction sent by a contract, the authorization context includes the
Since the initial version of EOSIO software, an alternative path existed to bypass the typical authorization checking described above for certain inline actions or contract-generated deferred transactions. If the inline action's code account is the same as the account of the contract sending the inline action, or if all the actions in a contract-generated deferred transaction have the same code account which is the account of the contract sending the deferred transaction, then the authorization bypass was utilized.
The motivation behind this bypass was that a contract could already do within the sending contract all the internal table changes that could be done during the execution of an inline action or a deferred transaction. So the bypass allowed the contract to avoid the strictness of the general authorization checks, enabling more flexible behavior in smart contracts.
However, this analysis missed the fact that the bypass opened up a privilege escalation vulnerability due to the fact that the authorizations of an action are also used by the native blockchain code to determine which accounts can be billed RAM by the contract. The authorizations of the original actions in a transaction (whether input or deferred) are also used by the native blockchain code to determine which accounts are to be billed for the CPU and network bandwidth of the transaction. This privilege escalation attack effectively meant that a contract exploiting this vulnerability could store data in its tables that charged the RAM costs for storing that data to any existing EOSIO account (without requiring that account to even be active in this process at all). However, the vulnerability could NOT be exploited to change the contract code or table data of other accounts, and there was no possibility of this exploit being used to steal tokens or other EOSIO digital assets (other than RAM and CPU/network bandwidth).
A subjective mitigation (released with v1.5.1 of EOSIO) has been available for over a month for live EOSIO blockchains to adopt which restricts the authorization rules when sending inline actions or deferred transaction such that this vulnerability cannot be exploited as long as all the active block producers of the network are running a version of nodeos including the patch for their block producing nodes.
The subjective mitigation effectively removes the bypass when sending deferred transactions meaning under this subjective mitigation the authorization for contract-generated deferred transactions is consistent with the general authorization rules described above which already applied to the original actions in an input transaction.
The subjective mitigation does not enforce as strict of a restriction for sending inline actions. The bypass rules have been restricted in the subjective mitigation to protect users' RAM and CPU/network bandwidth. But the authorization checks when sending an inline action are still more flexible than the general authorization rules that apply to original actions in an input transaction. This flexibility was purposely added to the subjective mitigation to reduce the number of existing well-meaning contracts deployed on live EOSIO blockchains that would break because they inadvertently relied on the unintentional flexibility of the bypass rules.
The subjective mitigation has been critical to quickly protecting users' RAM, but it is not a long-term solution. The long-term solution requires making the restrictions objective through a consensus protocol upgrade. Furthermore, for the sake of consistency, it is desirable for the authorization checks on inline actions to be as strict as the authorization checks on the original actions in an input transaction or the authorization checks on sending a deferred transaction now with the subjective mitigation in place. In other words, it is desirable for a consensus protocol upgrade to remove the bypass entirely.
This intention to further restrict the authorization checking behavior for sending inline actions has already been signaled through the deprecation notice in the v1.5.1 release of EOSIO. Since it will take some time before a consensus protocol upgrade to remove the bypass is activated, contract developers have some time to upgrade their contracts to not rely on the bypass.
Consensus upgrade feature
The goal of this consensus protocol upgrade feature is to remove the authorization checking bypass that applied when a contract sent an inline action to itself or when it sent a deferred transaction consisting of only actions to itself. With this change, the authorization checking behavior for actions becomes consistent regardless of whether the actions are the original actions in an input transaction, actions included in a contract-generated transaction, or inline actions sent by a contract.
A new consensus protocol upgrade feature will be added to trigger the changes described in this consensus upgrade proposal. The actual digest for the feature understood at the blockchain level is to be determined. For the purposes of this proposal the codename
The actual code changes to implement this are straightforward after the necessary protocol feature foundations are in place.
should instead be set to true iff
should instead be set to true iff