EOSIO v1.4.5 Release Notes
This release provides critical security bug fixes.
Mitigations
Use of Un-satisfied Authorizations in Self-addressed Actions and Transactions
This release contains subjective mitigations that will disallow any inline action or deferred transaction sent by a contract to itself that does not meet the following criteria:
For Self-Addressed Deferred Transactions
- Only allow authorizations that
- are satisfiable by
eosio.code
- AND meet the minimum permission of the action as linked by the
actor
present in the authorization
- are satisfiable by
For Self-Addressed Inline Actions Sent From Direct Actions
- Only allow authorizations that
- are satisfiable by
eosio.code
OR are present in the parent action - AND meet the minimum permission of the action as linked by the
actor
present in the authorization
- are satisfiable by
For Self-Addressed Inline Actions Sent From Recipient Handlers
- Only allow authorizations that
- are satisfiable by
eosio.code
- AND meet the minimum permission of the action as linked by the
actor
present in the authorization
- are satisfiable by
Inline actions and deferred transactions sent to any other contract are unaffected by this change and remain secure.
Contract authors are advised to audit their code for instances where self-addressed inline actions and deferred transactions with improper authorizations may have slipped through as those contracts will no longer function properly.
For more information see the official block.one blog post
DEPRECATION NOTICE
The propagation of authorizations present on the parent action for self-addressed inline actions sent from direct actions is DEPRECATED IMMEDIATELY and will be removed during the first protocol upgrade. At that time only properly formed authorizations satisfiable using the eosio.code
pattern will be allowed for any inline action or deferred transaction.
Contract Developers should take immediate action to refactor their contracts to not rely on these propagated authorizations.