Malicious shard might create hash conflicts in receipts

[evgenykuzyakov]

if a shard is completely compromised it can produce a receipt with a conflicting hash. E.g. the hash might conflict either with some other receipt or with a transaction. For a transaction it would trigger failed to decode during borsh. For a receipt we might return a wrong receipt or have receipt conflicts.
Eventually it will be challenged and reverted, but we need to make sure it doesn’t crash the node and we handle it correctly.

[evgenykuzyakov]

Here is the scenario:

1. A malicious chunk producer creates an invalid chunk with invalid transition.
2. This chunk is included in the block and no one challenged this chunk.
3. A new malicious chunk is produced on top the previous malicious chunk.
4. A malicious challenge is created for the 2nd malicious chunk. The challenge is legit by itself, but it's built on top of 1st malicious chunk. The 1st chunk may contain any state and any state root, because it was invalid. So the state proof in the challenge is valid.
5. When every regular node tries to validate a malicious challenge they might crash on any unexpected storage operation.

The 2nd chunk can also contain any invalid transactions or receipts. So the input to the Runtime can be almost arbitrary picked by the malicious nodes.

[MaksymZavershynskyi]

Assigning to @SkidanovAlex since it might be triggering failure on chain side.

[bowenwang1996]

Is this fixed in #2155?

[MaksymZavershynskyi]

Is this fixed in #2155?

Assigning to @evgenykuzyakov to provide reply.

[evgenykuzyakov]

It's addressed on Runtime side. I think Runtime is pretty safe, since it doesn't have unwraps or expects and doesn't trust the state at all.
It's likely still an issue on RPC side and maybe on chain side

[bowenwang1996]

I don't think it's an issue on the rpc side given that we prohibit querying receipts. On the chain side I don't see any issue since the content of receipts is not important from chain's perspective.

[evgenykuzyakov]

So if a shard produces an invalid ExecutionOutcome with the result SuccessReceiptId pointing at the transaction itself. It might create the infinite recursion during fetching of get_recursive_transaction_results

[bowenwang1996]

@evgenykuzyakov that's fine. The query will just time out. If you are talking about the node answering the query, since the shard is corrupted I don't think we need to worry about the safety of a malicious node.

[MaksymZavershynskyi]

@bowenwang1996 AFAIU this attacks honest validator.

[bowenwang1996]

This can only happen if the shard is controlled by a malicious majority, which means that honest validators, if any, will submit a challenge, and I think it is fine if they are temporarily subject to this attack before the chain confirms the challenge and slash malicious actors. Also moving this to post mainnet milestone as we will not have multiple shards first.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[bowenwang1996]

looks like no action items here. Closing