Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can you abuse size-indicators? #173

Open
Sword-Smith opened this issue Jul 31, 2024 · 0 comments
Open

Can you abuse size-indicators? #173

Sword-Smith opened this issue Jul 31, 2024 · 0 comments

Comments

@Sword-Smith
Copy link
Member

Sword-Smith commented Jul 31, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant