вт, 21 апр. 2020 г. в 19:13, Tim Düsterhus <t...@bastelstu.be>:
> Ilya, > > Am 21.04.20 um 15:47 schrieb Илья Шипицин: > >> The write-up is available now: > >> https://bugs.chromium.org/p/project-zero/issues/detail?id=2023 > >> > >> It has a "Methodology-Fuzzing" label, so after CVE-2018-14645 and > >> CVE-2018-20615 this is the 3rd CVE within H2 found using fuzzing that > >> I'm aware of. It probably won't be the last. Can we please allocate some > >> resources on making HAProxy more fuzzer friendly after 2.2 is out? > >> > >> I would also be interested in how Felix Wilhelm performed the fuzzing, > >> do you happen to have details about that? > >> > > > > h2spec is very close to fuzzing. so, we just fire numerous requests and > see > > what's going on. > > > > ok, couple of things missing - core dump catch and address sanitizing. > not > > hard to add. > > > > the question is "how to generate h2 fuzzing workload" > > > > The two CVEs I mentioned were bugs *I* found using afl-fuzz. The biggest > hurdle back when I attempted fuzzing was not getting an appropriate > workload (I've just created a few basic requests using nghttp), but > instead getting the requests into HAProxy in a way so that afl is able > to detect branches that change based on input changes. This branch > detection is *the* main selling point of afl. Just sending random > garbage is not going to turn up interesting stuff, if anything. > I really beleive that people who can perform fuzzing are smarter than me. But I hope to be able to run fuzzing some day :) what are "branches" ? are them git branches ? do you have any setup step-by-step described how those CVE were detected ? > > For CVE-2018-14645 this worked well, because I could use the standalone > hpack decoder. For CVE-2018-20615 I worked with preeny/desock and saw > that issues with branches being non-deterministic (I assume slight > timing issues or packets being cut differently or something like that). > > Best regards > Tim Düsterhus >
