Tox.im

[Lodewijk andré de la porte]

2014-07-08 21:53 GMT+02:00 Dāvis Mosāns <davispuh at gmail.com>:

> Also what about NUL bytes? I bet most parsers are implemented in C/C++
> using typical char * null-terminated string, how'll pass this JSON to
> someone? because well NUL...


At the parser level you would find a "b" character that's not between
brackets, signalling a binary header is coming. A binary header is actually
just the number of bytes that follow in binary format. The following bytes
are then a binary file, to be assigned to a string as if it were a
variable. We have a binarybuffer in javascript, that sort of thing. It
would contain the NULL byte if you like it to.

That may break some parsers, but this is the real life. Parsers must deal
with malformed input securely already > being unaware of bencoding2 should
not cause problems.

If the length-indicating thingy is short of what it should binary will
spill over into your JSON document. It may represent perfectly fine JSON,
and thus opens up binary overflow as a possible JSON hack. Someone that can
alter that number can already hack your JSON, so that doesn't actually
change any attack profile.

If it's too long it will gobble up your JSON file, which opens up reading
the rest of the file and maybe even into random memory and treating it as a
file in your JSON. That's much more serious but requires the JSON parser to
have bugs.

The thing is that if you don't cut yourself in the fingers it can be nice
to have a knife. If you don't write some pretty obvious bugs you will be
fine.

I think it's much more serious that you have to serve the BJSON completely
as a binary file. It's not like you can dump it onto a webpage anymore. You
can't slip it into your normal HTTP text transfer bodies either, has to
work with attachments. Attachments should be secure when facing malformed
transfers* etc. Inconvenient, but not the end.

* It would be pretty wack to mess with the HTTP protocol. Maybe you could
confuse a keep-alive connection to serve a file before it should be,
confusing a webapp or sending a redirect. Haven't really looked into it and
haven't really heard about it either. Maybe servers are just secure enough
against those attacks?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 2876 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20140708/a54dd4da/attachment-0001.txt>