nano-node icon indicating copy to clipboard operation
nano-node copied to clipboard

Validate representative field to avoid storage of arbitrary data

Open WckdPfizer opened this issue 3 years ago • 5 comments

Summary

Validation of the representative field is not implemented yet, which will lead to severe misusage in the near future if nothing is done against it. This issue can be relatively easy solved by adding a simple block height check (block height of representative chain > 0) to the existing block validation logic.

Node version

All

Build details

OS and version

All

Steps to reproduce the behavior

  1. Generate a random 32 byte public key and convert it into a Nano address
  2. Set the representative field of a valid change, send or receive block to the randomly generated address
  3. Publish the block to the Nano network by using the "process" RPC

Expected behavior

The "process" RPC should fail in case the representative is invalid.

Actual behavior

The "process" RPC doesn't fail and the block gets published and processed, though it shouldn't.

Possible solution

Check if the representative account has a blockchain height higher than zero. If the account height is above zero, then it should be sufficient proof that the address is not encoding meaningful data.

Supporting files

No response

WckdPfizer avatar Dec 28 '21 22:12 WckdPfizer

In the possible solution - I guess by checking if blockchain height is > 0 then you don't allow an account to select itself from the beginning as its own representative as it won't be able to publish an open block, instead would have to select an alternative valid representative and then switch back once the chain is open.

  • perhaps this is acceptable as a solution though (as its nice and simple)

jamescoxon avatar Dec 29 '21 19:12 jamescoxon

In the possible solution - I guess by checking if blockchain height is > 0 then you don't allow an account to select itself from the beginning as its own representative as it won't be able to publish an open block, instead would have to select an alternative valid representative and then switch back once the chain is open.

Thanks, the updated condition would be something like IF block->representative == block->account || block->representative->height > 0

WckdPfizer avatar Dec 29 '21 23:12 WckdPfizer

What happens if a node hasnt received the open block of that representative account yet, for whatever reason? Maybe same as sending a receive block with an unknown send block hash (node ditches it after a while)?

shryder avatar Dec 30 '21 09:12 shryder

What happens if a node hasnt received the open block of that representative account yet, for whatever reason? Maybe same as sending a receive block with an unknown send block hash (node ditches it after a while)?

Invalid blocks via the RPC should get rejected immediately. Incoming blocks from the network should be handled the same like receive blocks with unknown send blocks.

WckdPfizer avatar Dec 30 '21 14:12 WckdPfizer

Noting here a related conversation in the forums: https://forum.nano.org/t/threat-of-mass-usage-of-the-rep-field-for-arbitrary-data/2497

zhyatt avatar Jan 03 '22 21:01 zhyatt