Zipbomb JSON.
-
Zipbomb JSON.
Someone who is not me should formulate a maximally-malicious JSON file. I made one with a nesting depth of ~182 million, but "jq" gives up early, at only around depth 3,000. So one trick would be to find the right balance of nesting and array length that stays under typical parsers' limits as long as possible, while requiring as much RAM as possible to get there.
https://jwz.org/b/yk2x@jwz what formats support spare files?
-
Zipbomb JSON.
Someone who is not me should formulate a maximally-malicious JSON file. I made one with a nesting depth of ~182 million, but "jq" gives up early, at only around depth 3,000. So one trick would be to find the right balance of nesting and array length that stays under typical parsers' limits as long as possible, while requiring as much RAM as possible to get there.
https://jwz.org/b/yk2x@jwz yaml could be a good target for this too since it canonically supports references and ways to modify referenced data.
this python
print('a0: &t0')
print(' f0: v0')for x in range(33):
print(f'a{x+1}: &t{x+1}')
print(f' <<: *t{x}')
if x > 2:
print(f' <<: *t{x-1}')
print(f' f{x+1}: v{x+1} #override')
print(f' g{x+1}: w{x+1} #override')generates a yaml file that takes a while to load in python's yaml parser:
$ time python3 tl.py
real 0m31.946s
user 0m31.629s
sys 0m0.286s40 steps gets the python interpreter over 5 gig (i'm too lazy to run this to completion) using just 2872 bytes of input.
-
Zipbomb JSON.
Someone who is not me should formulate a maximally-malicious JSON file. I made one with a nesting depth of ~182 million, but "jq" gives up early, at only around depth 3,000. So one trick would be to find the right balance of nesting and array length that stays under typical parsers' limits as long as possible, while requiring as much RAM as possible to get there.
https://jwz.org/b/yk2x@jwz would it be possible to do recursive JSON??
-
@jwz yaml could be a good target for this too since it canonically supports references and ways to modify referenced data.
this python
print('a0: &t0')
print(' f0: v0')for x in range(33):
print(f'a{x+1}: &t{x+1}')
print(f' <<: *t{x}')
if x > 2:
print(f' <<: *t{x-1}')
print(f' f{x+1}: v{x+1} #override')
print(f' g{x+1}: w{x+1} #override')generates a yaml file that takes a while to load in python's yaml parser:
$ time python3 tl.py
real 0m31.946s
user 0m31.629s
sys 0m0.286s40 steps gets the python interpreter over 5 gig (i'm too lazy to run this to completion) using just 2872 bytes of input.
@prozacchiwawa @jwz Are there good resources on how to armor parsers against this sort of thing? Without having to resort to "run this thing in a padded cell cgroup with limited CPU percent and limited execution time"? (since that's not very portable to say, a microcontroller)
-
@prozacchiwawa @jwz Are there good resources on how to armor parsers against this sort of thing? Without having to resort to "run this thing in a padded cell cgroup with limited CPU percent and limited execution time"? (since that's not very portable to say, a microcontroller)
@developing_agent @jwz
i don't actually know for yaml, but it'd be good if a standard reference like that existed. -
Zipbomb JSON.
Someone who is not me should formulate a maximally-malicious JSON file. I made one with a nesting depth of ~182 million, but "jq" gives up early, at only around depth 3,000. So one trick would be to find the right balance of nesting and array length that stays under typical parsers' limits as long as possible, while requiring as much RAM as possible to get there.
https://jwz.org/b/yk2x@jwz it has always been surprisingly hard to crash JSON parsers, or even to get them to time out. See https://seriot.ch/software/parsing_json.html.
If attacking the parser is not an option, we are back to filling memory, which can probably be done by using really big strings. Presumably you do not want to store and transfer all those bytes, so you gzip them, and then it is just a gzip bomb with an extra layer: gzip bomb needs to expand into something that seems like JSON to the parser.
-
Zipbomb JSON.
Someone who is not me should formulate a maximally-malicious JSON file. I made one with a nesting depth of ~182 million, but "jq" gives up early, at only around depth 3,000. So one trick would be to find the right balance of nesting and array length that stays under typical parsers' limits as long as possible, while requiring as much RAM as possible to get there.
https://jwz.org/b/yk2x@jwz I have no visibility into your bot traffic, apologies if this is useless: If they send `Accept-Encoding: ...br...` you can hand out a Brotli file with much higher compression than gzip. I did an ad-hoc test of compressing `[[[...]]]` with 100 million layers, and the resulting compressed file was ~350 bytes.
-
@jwz I have no visibility into your bot traffic, apologies if this is useless: If they send `Accept-Encoding: ...br...` you can hand out a Brotli file with much higher compression than gzip. I did an ad-hoc test of compressing `[[[...]]]` with 100 million layers, and the resulting compressed file was ~350 bytes.
@danfuzz I tried that, but Brotli is not widely supported, even by Google. It is the WebP of compression algorithms.
-
@prozacchiwawa @jwz Are there good resources on how to armor parsers against this sort of thing? Without having to resort to "run this thing in a padded cell cgroup with limited CPU percent and limited execution time"? (since that's not very portable to say, a microcontroller)
@developing_agent @prozacchiwawa @jwz The first component in the parser is gonna be some kind of loop iterating over input tokens. Recognition of a single token is typically either O(1) (e.g. punctuation) or built from O(1) subtasks (e.g. literals). Putting something like
if (++work > LIMIT) abandon_ship();
after each of these might be worth a shot.
-
Zipbomb JSON.
Someone who is not me should formulate a maximally-malicious JSON file. I made one with a nesting depth of ~182 million, but "jq" gives up early, at only around depth 3,000. So one trick would be to find the right balance of nesting and array length that stays under typical parsers' limits as long as possible, while requiring as much RAM as possible to get there.
https://jwz.org/b/yk2xOk FINE, since you have all failed me, I wrote my own JSON bomb generator. https://jwz.org/b/yk2x
-
Ok FINE, since you have all failed me, I wrote my own JSON bomb generator. https://jwz.org/b/yk2x
@jwz In
make_stringyou set$btto an escaped version of$base_text, but then all the concatenations after that use$base_textinstead of$bt. It seems like this is a mistake, as the final quotes at the end seem like they should be surrounding escaped text. Or did I miss something? -
Ok FINE, since you have all failed me, I wrote my own JSON bomb generator. https://jwz.org/b/yk2x
@jwz I can't help but smile a little that people are still using perl to make the internet a better place.
-
@jwz In
make_stringyou set$btto an escaped version of$base_text, but then all the concatenations after that use$base_textinstead of$bt. It seems like this is a mistake, as the final quotes at the end seem like they should be surrounding escaped text. Or did I miss something?@ricko Thanks. I guess It'll go over the limit slightly if you use text it has to escape.
-
@ricko Thanks. I guess It'll go over the limit slightly if you use text it has to escape.
@jwz For the lols, I've ported this to TypeScript and published it to npm. So people who fear perl but have some moderately modern version of node installed can do:
npx @rickosborne/jsonbomb@latest
# or, with args
npx @rickosborne/jsonbomb@latest --max-size 1G | gzip --best > bomb.json.gzLicensed under the same terms as yours, with lots of README and source linkage back to yours.
-
Ok FINE, since you have all failed me, I wrote my own JSON bomb generator. https://jwz.org/b/yk2x
@jwz in Perl no less!
-
@jwz in Perl no less!
@jsatk I like languages that are *stable* and don't require me to have 7 different versions installed at once.
-
@jsatk I like languages that are *stable* and don't require me to have 7 different versions installed at once.
@jwz brother I hear you. As someone who has written JavaScript for 17 years I’m exhausted by all the changes to it and node.
-
R relay@relay.infosec.exchange shared this topic
