^{Originally posted by lunfardo314 January 21, 2022}

An attack with fake outputs

Assumptions

• New Stardust output types introduce metadata in outputs. It is not interpreted by the protocol, so fro the L1 it can be any
• The node API provides to clients only outputs and their IDs, in pairs.
• Transactions are not stored on the node, they are pruned, therefore not available for the client.
• There's no way for the client to check if the data provided with output ID is genuine.

The attack

Malicious public node which wallet is connected to, can easily fake the output data, while keeping genuine output IDs. Wallet has no means to check validity of it.

Specifically, mutable metadata block is not validated by the protocol, therefore it can be replaced by arbitrary data.

This feature makes it possible for the malicious node attack the L2 apps which interpret metadata field in it own way.

Examples

Bad Eve

Alice is running an app:

• the app permanently reads her donations address and collects the iotas sent to her by consuming UTXOs and consolidating iotas in her another address
• If the UTXO with output also contains metadata block, the app interprets the message by posting it as a string to Alice's public website together with the donated amount.
• Eve run a public node. She modifies the node's API the following simple way: in all requested by API outputs in metadata block she replaces all occurrences of string love to hate.
• Bob donates 1000i to Alice by sending UTXO with metadata field I love you.
• Eve provides the UTXO with faked metadata block to Alice
• Alice consumes faked UTXO, collects the donation and displays message 1000i from Bob: I hate you.
• this way any the love expressed to Alice will be converted into hate without good way to detect it, because consumed UTXOs will soon be pruned

Potential stealing of funds

If L2 wallet interprets the metadata block as a command to send funds or sender block as owner of funds, the funds can easily be stolen with this attack. This is exactly the case Stardust VM, especially if smart contract chain is run with one validator.

Proposed solution at the protocol level

In the protocol, we can require hash of all concatenated data of inputs used to produce the transaction by the wallet as a part of the transaction essence (signed).

This way the transaction will contain not only output IDs of outputs, but also commitment to the data of outputs used to produce the transaction.

The validation of transaction should be extended with checking in the validation context if hash of referenced outputs by inputs is equal to the hash included into the essence. If wallet used faked inputs, the transaction will be invalidated.

Pros

• it prevents the attack. Malicious node will not be able to make the wallet to produce wrong transaction
• solution is a simple extension of the protocol in iota.go
• storage overhead is only 32 bytes per one transaction
• we can keep sending only outputs from API (alternatively we would need to keep and send entire transactions)

Cons

• some, rather small, processor overhead in transaction validation
• the client still won't be able to detect faked output data. The produced transaction will look valid to the wallet (however it won't be confirmed)