ср, 22 апр. 2020 г. в 00:06, Tim Düsterhus <t...@bastelstu.be>:
> Ilya, > > Am 21.04.20 um 20:49 schrieb Илья Шипицин: > > I thought of some more high level fuzzing without intercepting code path. > > for example, we know about range queries > > > > Range: bytes=0-1023 > > > > > > i.e. bytes=(integer)-(integer) > > > > > > what if we send > > > > Range: bytes=1023-0 > > > > or > > Range: bytes=1023 > > > > or > > > > Range: bytes=abc-def > > > > and so on. > > it does not require any code modification. but proper workload generator > > should be chosen > > > > That would not be the job of a fuzzer, but that of a HTTP compliancy > checker, because that deals with business logic. Someone would need to > encode all the rules and edge cases laid out in the RFC into a program, > like someone did for h2spec. You don't need to have any smartness within > that checker, sending static requests and reading the responses is > sufficient there. > I heard of "level 2" fuzzing https://blog.tox.chat/2015/09/fuzzing-the-new-groupchats/ i.e. fuzzing on top of protocol implementation > > A fuzzer attempts to generate data that trips over the input parsers in > a way a human would not think of, because it's not an "obvious" edge > case. For CVE-2018-14645 the bug would trigger when receiving values > exceeding the range of an int, which might be an obvious edge case for a > C developer, but is not something that's specifically acknowledged > within the H2 specification. Negative values however are clearly invalid > when talking about a byte range. > > Best regards > Tim Düsterhus >
