6 ms·

My takeaway from this is that you can submit a long string of brackets to REST apps built with Haskell and Ruby/Oj and crash the process and/or machine by consu

My takeaway from this is that you can submit a long string of brackets to REST apps built with Haskell and Ruby/Oj and crash the process and/or machine by consuming all available RAM. Whereas the smarter JSON processors near the top of the list will abort processing pathological inputs before serious harm occurs. Wait, which JSON parsers are supposed to be "bad"?

lovasoa 7y ago
Well, most JSON parsers (haskell being a notable exception) use an amount of memory that is proportional to the size of the input, independently of whether they can parse deeply nested structures or not. Saying that a parser that does not limit the nesting depth will crash your server does not make any sense. You could as well say that str_replace will crash your server.
Spivak 7y ago
Just because a structure is deeply nested doesn’t mean that it consumes a lot of memory. And just because your payload is massive and consumes a lot of memory doesn’t mean it’s deeply nested. I doubt any of the parsers are resilient against storing large documents in memory. What makes them bad is that structures that would easily fit in memory are unparsable. In most cases your web server imposed a limit on the size of the HTTP payload so you wouldn’t normally be able to deliver a 128GiB JSON file anyway. It’s not like nested structures are zip-bombs.
- stickfigure 7y ago
  My comment was mostly tongue-in-cheek but there's some truth to it. Since the receiver creates a navigable data structure with 64-bit pointers, every two bytes sent ("[]") becomes 20+ bytes in RAM (low estimate!). An order of magnitude magnification helps.
vbezhenar 7y ago
You can do exactly the same by submitting endless string.
rurban 7y ago
The problem is not DOS by memory exhaustion, the problem is stack-overflow. You can trivially control the return address of the decoder. On mostly public interfaces! And I think I was the very first one whose JSON library knew about that, probed for the max depth (which is system dependent) and added hard and soft limits to it. It's not even mentioned in this post.
- NobodyNada 7y ago
  > You can trivially control the return address of the decoder. With a stack overflow? Stack overflows usually write to unmapped memory and cause a segmentation fault; how would you use that to control the return address? Or perhaps you were thinking about a stack buffer overflow instead? https://en.wikipedia.org/wiki/Stack_overflow https://en.wikipedia.org/wiki/Stack_overflow vs https://en.wikipedia.org/wiki/Stack_buffer_overflow https://en.wikipedia.org/wiki/Stack_buffer_overflow
  - rurban 7y ago
    In this case it's the same. The max stack depth is known, and the overflow easily triggerable and controllable from outside. It cannot get much easier. Wikipedia is a bit confused.
    - NobodyNada 7y ago
      It’s trivial to cause a stack overflow (as in allocating too much memory and running out of stack space), but how would you overwrite the return address? From what I can tell, the attacker can only cause the application to allocate lots of memory, not to overwrite memory.
      - rurban 7y ago
        Memory DOS will not happen with normal recursion, only a tradional stackoverflow. And by adding some content after the fixed number of [ or {, this will by on the stack as argument to the recursive function. There are so many possible exploits. See eg. https://jon.oberheide.org/files/infiltrate12-thestackisback.pdf https://jon.oberheide.org/files/infiltrate12-thestackisback.... or search for "stack overflow recursion exploit"

lovasoa 7y ago

Well, most JSON parsers (haskell being a notable exception) use an amount of memory that is proportional to the size of the input, independently of whether they can parse deeply nested structures or not. Saying that a parser that does not limit the nesting depth will crash your server does not make any sense. You could as well say that str_replace will crash your server.

Spivak 7y ago

Just because a structure is deeply nested doesn’t mean that it consumes a lot of memory. And just because your payload is massive and consumes a lot of memory doesn’t mean it’s deeply nested. I doubt any of the parsers are resilient against storing large documents in memory. What makes them bad is that structures that would easily fit in memory are unparsable. In most cases your web server imposed a limit on the size of the HTTP payload so you wouldn’t normally be able to deliver a 128GiB JSON file anyway. It’s not like nested structures are zip-bombs.

stickfigure 7y ago
My comment was mostly tongue-in-cheek but there's some truth to it. Since the receiver creates a navigable data structure with 64-bit pointers, every two bytes sent ("[]") becomes 20+ bytes in RAM (low estimate!). An order of magnitude magnification helps.

vbezhenar 7y ago

You can do exactly the same by submitting endless string.

rurban 7y ago

The problem is not DOS by memory exhaustion, the problem is stack-overflow. You can trivially control the return address of the decoder. On mostly public interfaces! And I think I was the very first one whose JSON library knew about that, probed for the max depth (which is system dependent) and added hard and soft limits to it. It's not even mentioned in this post.

NobodyNada 7y ago
> You can trivially control the return address of the decoder. With a stack overflow? Stack overflows usually write to unmapped memory and cause a segmentation fault; how would you use that to control the return address? Or perhaps you were thinking about a stack buffer overflow instead? https://en.wikipedia.org/wiki/Stack_overflow https://en.wikipedia.org/wiki/Stack_overflow vs https://en.wikipedia.org/wiki/Stack_buffer_overflow https://en.wikipedia.org/wiki/Stack_buffer_overflow
- rurban 7y ago
  In this case it's the same. The max stack depth is known, and the overflow easily triggerable and controllable from outside. It cannot get much easier. Wikipedia is a bit confused.
  - NobodyNada 7y ago
    It’s trivial to cause a stack overflow (as in allocating too much memory and running out of stack space), but how would you overwrite the return address? From what I can tell, the attacker can only cause the application to allocate lots of memory, not to overwrite memory.
    - rurban 7y ago
      Memory DOS will not happen with normal recursion, only a tradional stackoverflow. And by adding some content after the fixed number of [ or {, this will by on the stack as argument to the recursive function. There are so many possible exploits. See eg. https://jon.oberheide.org/files/infiltrate12-thestackisback.pdf https://jon.oberheide.org/files/infiltrate12-thestackisback.... or search for "stack overflow recursion exploit"