Impact

Exchanges on the Stellar network often “multiplex” their accounts, resulting in, effectively, different accounts under the exchange umbrella that don’t have individual account representations on the blockchain. Exchanges have taken to using the memo field as a way of tagging specific movements of tokens to specific accounts.

With the introduction of the Soroban smart contract platform last year, so-called “C” custom account addresses were introduced. Custom accounts have custom authorization implementations backed by a smart contract. Authorization for the transactions is provided by a SorobanAuthorizationEntry (SorobanAuth) object (see CAP 46-11 here).

When a SorobanAuth object is created, information about the smart contract interaction (e.g. destination and token transfer amount) is hashed and then signed. This ensures that the details of the interaction are not changeable. However, the memo field is not part of the hashing done for the authorization process as there can be many Soroban calls in one transaction (and there is only one memo per transaction).

When a SorobanAuth object is created, it is an “authorization to operate” during the lifetime of that transaction. However, there is nothing that ties the authorization to the specific transaction it was originally intended for. Thus, a malicious attacker could front-run a transaction, take the signed SorobanAuth object, and put it into a different transaction with a different destination memo. This vulnerability creates the opportunity to maliciously “front-run” a transaction. For example:

• A user owns a 'deposit' exchange account that is a pair (G$EXCHANGE_ACCOUNT, 123) (123 is memo)
• Custom account signs a soroban auth payload to transfer 1 XLM from its balance to account G$EXCHANGE_ACCOUNT
• Then owner of the account creates a transaction with memo 123 and attaches the signed auth from the previous step to it
• The attacker takes the soroban auth entry, creates their own transaction with memo 456 and front-runs the original transaction.
• In case if front-running is successful, the transfer is deposited to (G$EXCHANGE_ACCOUNT, 456)

When this was first identified, Stellar Development Foundation took immediate action to review and assess the impact of this vulnerability. During the time of this vulnerability being active, there were very few transactions which had both “Soroban Auth” objects and memo fields in use. Of those, none were multiplexing activities. Thus, during the time this vulnerability was present, it was not exploited.

Due to the High complexity of the attack and very focused impact, this severity is Low.

Patches

To quickly mitigate this vulnerability, a change was introduced in Protocol 22 (release 22.0.0) which prevented acceptance and processing of transactions for which both of the following conditions are true:

• The transaction contains a memo and/or muxed source account
• The transaction contains a Soroban authorization entry with Address credentials

While this change does mitigate the vulnerability, it prevents some valid potential use-cases in the future, such as smart-contract wallets wanting to issue transactions with memos.

It is important to note that transactions with memos that use only SOURCE_ACCOUNT credentials are not affected. Indeed, 99+% of Soroban transactions with non-blank memo fields on-chain fall into this last category and are unaffected by the mitigation.

References

Safely enabling memos with Soroban authorization entries is an important advancement for Stellar. SDF would like to open discussion up to the community for how this can best be accomplished. CAP-64 represents the current thinking for this remediation.