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. 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
