6 ms·
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
by aDyslecticCrow 4mo ago
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 4mo agoYou have the same issue with LEB128 though, right?
- pixelesque 4mo agoVery likely, but isn't this post claiming that bijou64 is safer than LEB128 for the situation of adversarial varints?
- aDyslecticCrow 4mo agoLEB128 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.)