0xMiden / 0xMiden/protocol

Prevent memory allocation of untrusted size

Offen
#1,347 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
Rust
Sterne
132
Forks
167
Ø Merge
1 T. 23 Std.
Gemergte PRs (30 T.)
110

Beschreibung

Closely related to https://github.com/facebook/winterfell/issues/377, there are some places where the value we pass to `ByteReader::read_many` can actually be very large. Even with the mentioned issue fixed, we should still prevent passing very large values whose allocation succeeds, but take up, say, 99% of available memory. In those cases, any other panicking memory API in other places could easily panic, because allocation of a small amount of memory would fail. In other words, we may want to put some reasonable limits in place.

This concerns:
- `AssetVault`: The number of assets is serialized as a `usize`.
- `FungibleAssetDelta`: The number of assets is serialized as a `usize`.
- `BlockNoteTree`: The number of leaves is serialized as a `u32`.

For the asset vaults: The question is what limit we can impose to avoid this issue. Perhaps we can limit the number of assets in an account to `u16::MAX`, or if that's too restrictive, then to something like $2^{20}$. Given 32 bytes per asset, that would be a maximum of 2 MiB in the `u16` case or 32 MiB in the $2^{20}$ case.

For the tree: Could this be a `u16`, i.e. match `MAX_OUTPUT_NOTES_PER_BLOCK`? I guess that is technically possible, but if we increase the size of the tree in the future, then that would be a breaking change at the serialization format. So maybe we just enforce a limit at deserialization time and keep `u32` for extensibility.

Beitragsleitfaden

Beitragsleitfaden öffnen

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.