Ilya,

Am 21.04.20 um 17:02 schrieb Илья Шипицин:
>> 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

Branches refer to branches within the generated machine code (i.e.
conditional jumps). AFL works similarly to ASAN in that it adds some
additional code to the executable to detect whether a branch was taken
(i.e. a jump happened) or not.

As a super simplified example consider the following code:

if (buf[0] == 'b') {
  if (buf[1] == '1') {
    crash();
  }
  // do something (1)
}
else {
  // do something (2)
}

I would then use the following as the initial payload:

buf = "a0"

AFL would then execute the "(2)" line. Afterwards it might try the
following (increase the first byte by 1):

buf = "b0"

AFL would then detect that something changed: Instead of jumping to the
'else' it would continue executing the second 'if'. Now AFL knows that
the first byte being 'b' is special (or at least different to 'a').
Instead of attempting 'c' it might then proceed to modify the second
byte. By incrementing it from '0' to '1' it notices that again something
changed: The program crashes.

This "intelligent" processing could find the bug with just 3 inputs
instead of having to randomly test 256*256 combinations for the two
bytes. In reality the results are even more impressive: AFL was able to
generate a valid JPG image based on the starting input 'hello'.

See this blog post:
https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin-air.html

> described how those CVE were detected ?
> 

I intended to write up a blog post after my initial find, but never got
around to it. For the first one it basically went like this:

1. Compile the standalone hpack decoder.
2. Start afl-fuzz with a single input on the decoder.
3. Wait 2 minutes.
4. Report security issue.

Not joking, it literally took 2 minutes of throwing data at the decoder
to find the issue on a single core cloud server. I believe you'll be
able to figure it out yourself. To reproduce the bug you need to check
out commit f7db9305aa8642cb5145bba6f8948400c52396af (that's one before
the fix).

The second one was more involved and less reliable. I used desock.so
from https://github.com/zardus/preeny to receive "network" input from
stdin and patched HAProxy to exit after serving a single request. Then I
used a simplistic configuration pointing to an nginx and seeded AFL
using some HTTP/2 requests I generated using nghttp against `nc -l >
request`. However that dirty hackery resulted in AFL not reliably
detecting whether something changed because the input changed or whether
it just randomly changed.

Best regards
Tim Düsterhus

Reply via email to