As we see more and more Cosmos based chains rolling out the “AuthZ” module we think it is important to have a larger debate on the potential security breach it can cause to unaware users. It is even more important to be proactive right here in the Hub because we also have the Liquid Staking Module module (LSM) which can further fuel the fire if combined with malicious AuthZ usage. As we wait to get an appropriate response from wallet providers introducing visible warnings on potential risky transactions approval, we need to have our community informed of both the wonders and the dangers that come along with this module.
Source: x/authz | Explore the SDK
x/authzis an implementation of a Cosmos SDK module, per ADR 30, that allows granting arbitrary privileges from one account (the granter) to another account (the grantee). Authorizations must be granted for a particular Msg service method one by one using an implementation of theAuthorizationinterface.
To give a bit of context for regular Cosmos users, this module makes it possible to use services like REStake | Auto-compound your staking rewards. Its utility covers a much wider range of potential use cases, including advanced account management, with many more expected to come in the future.
What users are less aware of is the dangerous capabilities this also carries. To explain what those are, let’s have a look at the types of transactions the authZ module can execute:
- MsgGrant: This is the initiation transaction to allow a certain type of action as well as specifying the conditions associated with that (more details later).
- MsgRevoke: To remove an existing Grant.
Therefore, users should pay extra attention to any transaction they sign on their wallet that is related to the MsgGrant function.
Here is an example of the signature required by Restake to perform their actions on your behalf, in which you can find the aforementioned MsgGrant as well as all the details associated with that request:
At the current time, there is no specific warning sign in the Keplr wallet related to an authz transaction. But it is imperative that users pay an extreme amount of attention to these custom transactions and understand what they are signing. It is unfortunate that protections are not yet in place to prevent users from signing without reading carefully. It will likely happen in the future, but in the meantime, the risk is real, and careless users could face serious harm if they sign malicious authZ transactions without reading.
To understand what a malicious authZ could look like, let’s break down the types of permissions that a MsgGrant can ask for:
- GenericAuthorization: implements the
Authorizationinterface that gives unrestricted permission to execute the provided Msg on behalf of granter’s account. YOU SHOULD BE VERY CAREFUL SIGNING SUCH TRANSACTION unless being strictly in control of what you’re about to do. These one can allow access to any module’s msg transaction types. For example, you may me comfortable signing a msg type corresponding to claiming rewards if it is related to a restake protocol. But if you have any doubts, always make sure to delay the operation and reach out to a competent person. Most of the time your validator representatives will be there to help you figuring out what is safe and what is not. - SendAuthorization: implements the
MsgSendauthorization, allowing the grantee to send coins from the granter’s balance. Arguments take a (positive)SpendLimitthat specifies the maximum amount of tokens the grantee can spend and an optionalAllowListthat specifies to which addresses a grantee can send token. - StakeAuthorization: it takes an
AuthorizationTypeto specify whether you want to authorise delegating, undelegating or redelegating (i.e. these have to be authorised seperately). It also takes a requiredMaxTokensthat keeps track of a limit to the amount of tokens that can be delegated/undelegated/redelegated. If left empty, the amount is unlimited. Additionally, this Msg takes anAllowListor aDenyList, which allows you to select which validators you allow or deny grantees to stake with.
Now you have all the necessary information to understand what an authZ transaction can do. It can be used for great purposes, but if left unchecked and signed carelessly, any malicious actor could be empowered with enormous capabilities over your wallet. It could spend your coins or do even more than that if you ever grant an unwanted GenericAuthorization to a scammer.
As we wait until wallets implement necessary warnings regarding authZ transaction signatures, it is up to the users to be extra careful themselves. This is why we think that it is our responsability as active community members right here in this forum to take the necessary actions in order to inform the broader community of Cosmos users.
We hope to hear from anyone having propositions to assess this situation. Anyone having direct contact to the wallet providers would be welcomed to initiate discussions on this matter with them. Influencers and content creators should also use their wider audience to inform users. These are the suggestions we have, don’t hesitate to share your own solutions if you have more.
Thanks for reading,
Govmos (the governance arm of the PRO Delegators’ Validator)
