The current implementation is prone to the cross-chain replay attacks

[hats-bug-reporter[bot]]

Github username: @rodiontr Twitter username: -- Submission hash (on-chain): 0x965952d681133a72600f8916bcc487bde452eaebb2291f928b13c807325b98ee Severity: medium

Description: Description\

The current implementation of signer_client doesn't make sure that the transaction is protected from replay attacks.

Attack Scenario\

In signer_client there is a method called sign_azero() that is used to send a payload to be signed with the Azero account's private key and awaits the signed payload. However, there is not any specific protection from replay attacks that are possible on other chains, for example:

https://github.com/Cardinal-Cryptography/most/blob/master/relayer/signer_client/src/lib.rs#L117-133

  pub async fn sign_azero(&mut self, payload: &[u8]) -> Result<MultiSignature, Error> {
        self.send(&Command::SignAzero {
            payload: payload.to_vec(),
        })
        .await?;

        match self.recv().await? {
            Response::SignedAzero {
                payload: return_payload,
                signature,
            } if return_payload == payload => Ok(signature),
            other => Err(Error::InvalidResponse {
                expected: format!("SignedAzero(payload: {:?})", payload),
                got: other,
            }),
        }
    }

For example, there is a another method called sign_eth_tx() that uses chain id for these purposes:

https://github.com/Cardinal-Cryptography/most/blob/master/relayer/signer_client/src/lib.rs#L171-177

 if let Response::SignedEthTx {
            tx: mut return_tx,
            signature,
            chain_id: return_chain_id,
        } = res.clone()

Attachments

Provided above.

Recommendations

Add chain id when signing the transactions.

[rodiontr]

Same thing also applies to sign_eth_hash as it's used to sign the hash with the signature but doesn't implement any measures to protect from replay attacks

[fbielejec]

In order for a submission to be concerned valid, please provide a Proof of Concept (POC) of an attack the utilizes the alleged vulnerability, as per submission guidelines.

Further notes:

• signer is a stateless, off-chain component that merely signs arbitrary payload (using a key within a hardware enclave)
• replay attacks only make sense in the context of smart contracts