NEAR / Defuse LabsNEAR Intents Security Review

Depending on the intent structure, it's possible to maliciously fail a transaction and then repeat specific intents, which could lead to:

Stealing tokens Making solvers lose money or perform unauthorized operations

Mainnet deadlines are permissive, ranging from 20 seconds to 10 minutes. This provides ample time to fail a transaction and repeat failed intents. A transaction can be failed by:

Invalidating the nonce after signing in a separate transaction. Adding an additional intent to your intent array that transfers funds out and fails your token diff

Malicious actor can:

Repeat selected intents. Repeat selected intents and, to maintain TokenDiff balance, resign your controlled intents with new values. Observe failed intents on the blockchain and reconstruct them like building blocks (while deadlines remain valid).

The risk is low when TokenDiff intent is used, as mainnet calculations are typically precise, making it difficult to modify the intent structure while maintaining zero delta and gaining benefits. The vulnerability is particularly dangerous in P2P transfer scenarios where TokenDiff intent isn't used, allowing for immediate exploitation with high success rates.

Impact:

Funds can be stolen in scenarios where TokenDiff intent isn't used.

Recommendation

This behavior should be documented to emphasize that TokenDiff is the preferred method, while Transfer should be discouraged for facilitating swaps. Users must understand they are responsible for reviewing and approving what they sign.

Remediation - Scheduled

The Aurora team has acknowledged the issue and will fix it soon by documenting this scenario.

It was observed that since user can have unlimited public keys, it is possible for a malicious user to cause a DoS of public_keys_of method when their account is used. That’s because public_keys_of iterates over public keys of a provided account and if account has a lot of public keys it can lead to the error due to a gas limit.

defuse/src/contract/accounts/mod.rs

     fn public_keys_of(&self, account_id: &AccountId) -> HashSet<PublicKey> {
                self.accounts.get(account_id).map_or_else(
                    || {
                        PublicKey::from_implicit_account_id(account_id)
                         .into_iter()
                         .collect()
                    },
                  |account| account.iter_public_keys(account_id).collect(),
                )
              }

Impact:

Errors in off-chain components, which utilize public_keys_ofmethod. If iter_public_keys is utilized within the smart contract logic somewhere else, depending on a logic it can lead to the DoS on protocol level

Recommendation

It is recommended to limit the number of public keys each account can have

Remediation - Not Fixed

The Aurora team has not fixed the issue yet.

The codebase accepts public keys in multiple locations without proper validation. The NEAR SDK's PublicKey type lacks comprehensive validation of public key formats and values. Malicious users could potentially inject invalid or malformed public keys, leading to undefined behavior in cryptographic operations.

PoC:

poc

       fn test_parse_zero_pubkey() {
              use near_sdk::PublicKey;
              let zero_pubkey_str = "ed25519:11111111111111111111111111111111";
              let result = zero_pubkey_str.parse::<PublicKey>();
              assert!(result.is_err());
              }

Impact:

Potential undefined behavior in cryptographic operations Potential injection of weak public keys that can lead to signature malleability

Recommendation

Implement comprehensive validation for public keys in all relevant functions.

Account Public Key Management (add_public_key, remove_public_key) Relayer Keys Management (do_add_relayer_key, delete_relayer_key) Full Access Keys Management (add_full_access_key, delete_key)

Remediation - Not Fixed

The Aurora team has not fixed the issue yet.

The relayer keys operations lacks event emissions for access control operations in delete_relayer_key() and do_add_relayer_key() methods. This omission makes it difficult to track and audit changes to the relayer key set off-chain. Events are essential for maintaining transparency and allowing external systems to monitor and react to important state changes in the contract.

Recommendation

Implement event emissions for both adding and removing relayer keys

Remediation - Not Fixed

The Aurora team has not fixed the issue yet.