docs(users/Profpatsch/netencode): Parser security considerations
Netencode parsers should probably set an upper length limit. Change-Id: Ibe65f2b59058106b720867a83435bf45660f1adf Reviewed-on: https://cl.tvl.fyi/c/depot/+/5908 Tested-by: BuildkiteCI Reviewed-by: Profpatsch <mail@profpatsch.de>
This commit is contained in:
parent
aea54af52e
commit
46f908c3c1
1 changed files with 18 additions and 0 deletions
|
@ -102,6 +102,24 @@ Similar to records, lists start with the length of their whole encoded content.
|
||||||
* The list with text `foo` followed by i3 `-42`: `[14:t3:foo,i3:-42,]`
|
* The list with text `foo` followed by i3 `-42`: `[14:t3:foo,i3:-42,]`
|
||||||
* The list with `Some` and `None` tags: `[33:<4:Some|t3:foo,<4None|u,<4None|u,]`
|
* The list with `Some` and `None` tags: `[33:<4:Some|t3:foo,<4None|u,<4None|u,]`
|
||||||
|
|
||||||
|
## parser security considerations
|
||||||
|
|
||||||
|
The length field is a decimal number that is not length-restricted,
|
||||||
|
meaning an attacker could give an infinitely long length (or extremely long)
|
||||||
|
thus overflowing your parser if you are not careful.
|
||||||
|
|
||||||
|
You should thus put a practical length limit to the length of length fields,
|
||||||
|
which implicitely enforces a length limit on how long the value itself can be.
|
||||||
|
|
||||||
|
Start by defining a max value length in bytes.
|
||||||
|
Then count the number of decimals in that number.
|
||||||
|
|
||||||
|
So if your max length is 1024 bytes, your length field can be a maximum `count_digits(1024) == 4` bytes long.
|
||||||
|
|
||||||
|
Thus, if you restrict your parser to a length field of 4 bytes,
|
||||||
|
it should also never parse anything longer than 1024 bytes for the value
|
||||||
|
(plus 1 byte for the type tag, 4 bytes for the length, and 2 bytes for the separator & ending character).
|
||||||
|
|
||||||
## motivation
|
## motivation
|
||||||
|
|
||||||
TODO
|
TODO
|
||||||
|
|
Loading…
Reference in a new issue