mdebray/tvl-depot
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(users/Profpatsch/netencode): Parser security considerations

Browse source 
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:
Profpatsch 2022-07-01 14:16:00 +02:00
parent aea54af52e
commit 46f908c3c1
1 changed files with 18 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
users/Profpatsch/netencode/README.md
View file

@ -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 `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
TODO