Can you abuse size-indicators?

[Sword-Smith]

The encoding and by extension the non-deterministically initialized memory often contains size-indicator that are used to find the next field or element in a list. If a malicious prover were to insert e.g. negative values here, they might allow some programs to read from outside of a section of memory that the programs expect.

I don't yet have a concrete attack on any program, but I fear that it might be possible to get data from another section of memory than what has been hashed and proved to be a part of the transaction kernel.

This issue was created so that we don't forget this potential issue during a security analysis.

Potential fixes:

1. Check all size-indicators and verify that they point to data within some range
2. Change all witness data structures used in ND-memory to avoid the need for dynamic size indicators
3. Manually implement BFieldCodec for all witness data structures used in ND-memory such that they contain no size indicators -- field sizes can still be dynamic but their size will have to be derivable from the number of elements in the sequence, I think. So each in a sequence must have a statically-known size, and then the size of the sequence will be derivable from its length.

On a similar note, we should also force the dynamic memory allocator to be initialized to zero such that provers cannot overwrite ND-memory (assumed to be stored between address 0 and u32::MAX) with the dynamic allocator by initializing the state of the dynamic allocator to a high number.