[aDyslecticCrow]

Clever, but one thought crossed my mind;

An adveserial package can claim to have a 255 tagged integer but not actually have any followup, tricking the payload parser into an incorrect offset and reading straight off into followup memory.

It's a classic thing to check for when dealing with variable length strings or binary, but it may not cross the mind when it's hiding in the Bijou64_decode(*buff, *cr) function.

[gregschlom]

You have the same issue with LEB128 though, right?

[aDyslecticCrow]

LEB128 can only trick you by at most one byte, (depending on the followup data). Bijou64 can consistently trick you by 8 bytes.

In a contrived example of a pbuf {length:int, payload:byte[1]}

LEB128 can trick you into reading the payload as part of the length, but then hopefully trigger a code check against invalid buffer read. (or one byte outside the struct if the payload is also malicious)

Binou64 can trick you to read 7 bytes into other memory, before any buffer size validation is done.

It's then not uncommon to log with a helpful; "buffer with length: 26624894573377(7 bytes of stolen data) is invalid", or just crash.

It's to the point that Bijou64_decode should perhaps take "end_adress" or "max_read" to catch this kind of attack.

(If you dont validate a malicious pbuf, you're in for a bad time regardless of integer format, but these int formats add their own way to trigger a buffer overrun despite a proper check.)

[pixelesque]

Very likely, but isn't this post claiming that bijou64 is safer than LEB128 for the situation of adversarial varints?