Foreign UTXO Tokens vulnerability

zmrocze commented 1 week ago

Severity	CVSS	Vulnerability Type
Medium	6.8	foreign-utxo-tokens

Description

The UpgradeableOwners validator ensures a correct propagation of datum into the continuing output. The validator doesn't check though the value locked at the output. This means two things:

any ADA value locked at the output being spent can get lost

but even more importantly:

transaction is allowed to lock a foreign tokens at the protocol output, possibly locking the protocol

Foreign tokens can lock the protocol because presence of them increases the size of an UTXO. In turn this increases the transaction size and execution budget that tries to spend the UTXO. Depending on the current parameters for the Plutus cost model - it can be possible to create a transaction locking huge amounts of foreign tokens at the UTXO output - but not one spending that UTXO again in consecutive transactions.

How to reproduce

An attacker can create a malformed transaction where he locks many previously minted foreign tokens at the protocol UTXO. If owners don't verify the transaction very carefully, they may accept such a transaction, risking halting the protocol.

Recommendation

The validator should check if the continuing output contains only the expected tokens, that is the NFT token and at least as much ADA as spent from the protocol input. This ensures no ADA is lost and offloads the verification of a fully correct protocol UTXO to the onchain validator, increasing protocol usability and security.

Timekiller7 commented 5 days ago

Hello, @zmrocze. Not sure that we understand what do you mean by unspendable token vulnerability. Can you explain a little bit more, please?

zmrocze commented 5 days ago

Hey @Timekiller7, right. I'll provide the detailed explanation with a test case that shows the vulnerability. The vulnerability happens because in the transaction that spends the NFT containing UTXO, you can send many tokens (completely unrelated to the protocol tokens) to the continuing output. If there is enough tokens it can make the resulting output unspendable because it is too big and the transaction size limits don't allow it to be spend. Of course this is a tricky case - the limits need to be just right for the spending transaction to succeed but another transaction to cannot succeed. Will provide more detail.

Timekiller7 commented 5 days ago

@zmrocze, ah, okey. I am aware of this issue. We were thinking about extra transaction validation in off-chain code from sides of all owners

singnet / snet-upgradeable-owners-minting-policy