nano-node
nano-node copied to clipboard
Validate representative field to avoid storage of arbitrary data
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
- Generate a random 32 byte public key and convert it into a Nano address
- Set the representative field of a valid change, send or receive block to the randomly generated address
- 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
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)
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
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)?
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.
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