New issue
Advanced search Search tips

Issue 753533 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
EstimatedDays: ----
NextAction: 2019-07-09
OS: Linux , All
Pri: 3
Type: Bug

Blocking:
issue 539572



Sign in to add a comment

AFL Driver - Environment Constructed in Parent Process

Project Member Reported by tjbecker@google.com, Aug 8 2017

Issue description

The LibFuzzer guide encourages fuzzer developers to use a global Environment struct to establish a fuzzing environment. This works well when running with LibFuzzer, but might not always work with AFL.

The AFL driver forks and runs the persistent mode loop in the child process, but the Environment struct was initialized in the parent process. This can break fuzzers whose environment holds state that is process-dependent. For example, the MessageLoop constructed in the mojo_parse_message_fuzzer must run the same process it was constructed:
https://chromium.googlesource.com/chromium/src/mojo/+/master/public/tools/fuzzers/mojo_parse_message_fuzzer.cc#78

A workaround would be to initialize the environment in the first call to LLVMFuzzerTestOneInput(), but this could cause inaccurate coverage feedback.
 
Blocking: 539572
Labels: -Pri-3 OS-All Pri-2
Kostya, is there a way you would recommend to get around this issue?

Comment 2 by kcc@google.com, Aug 8 2017

My typical recommendation is to do this: 

extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {
  static bool Initialized = DoInitialization();
  ...

Will this help here?

It shouldn't have dramatic effect on the accuracy of coverage
Yeah, this is the workaround suggested. It does fix the issue, but I was concerned about its effect on coverage accuracy, which I'm pleased to hear is not dramatic. Thanks!

Comment 4 by kcc@google.com, Aug 8 2017

Hm... Interesting. Now that I think more about this... 
The effect on coverage would be almost none for libFuzzer, but maybe for AFL it will be non-zero, given that the persistent mode loop runs N inputs and then restarts. 

Every N runs we will run the initialization code, but since it will always have the same coverage it should not cause AFL to add unwanted elements to the corpus. So, hmmm, looks like we are still fine. But frankly I did not spend too much time with AFL to assert this. 
Project Member

Comment 5 by bugdroid1@chromium.org, Aug 10 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f6303bc9704fb76154bf5377e2202370f232e63a

commit f6303bc9704fb76154bf5377e2202370f232e63a
Author: Tim Becker <tjbecker@google.com>
Date: Thu Aug 10 21:00:09 2017

Improve Mojo Fuzzer Coverage

Add an Associated Interface to FuzzInterface.

Initialize the Environment in the Fuzzer function to guarantee
it is constructed in the same process as it is used. This was
causing issues with the AFL driver, which runs the Fuzzer
function in a subprocess.

Dump messages from a filter in the MultiplexRouter instead
of in the InterfaceEndpointClient. Hooking the MultiplexRouter
allows us to dump messages before they are mutated during
processing and to catch messages going to associated interfaces.

R=ochang@chromium.org

Bug: chromium:753533
Change-Id: I9f9ea0a744cfe1fe26c46e21b3fb0da4fd8ca653
Reviewed-on: https://chromium-review.googlesource.com/604729
Commit-Queue: Timothy Becker <tjbecker@google.com>
Reviewed-by: Ken Rockot <rockot@chromium.org>
Reviewed-by: Oliver Chang <ochang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#493539}
[modify] https://crrev.com/f6303bc9704fb76154bf5377e2202370f232e63a/mojo/public/cpp/bindings/lib/multiplex_router.cc
[modify] https://crrev.com/f6303bc9704fb76154bf5377e2202370f232e63a/mojo/public/cpp/bindings/lib/multiplex_router.h
[modify] https://crrev.com/f6303bc9704fb76154bf5377e2202370f232e63a/mojo/public/tools/fuzzers/fuzz.mojom
[modify] https://crrev.com/f6303bc9704fb76154bf5377e2202370f232e63a/mojo/public/tools/fuzzers/fuzz_impl.cc
[modify] https://crrev.com/f6303bc9704fb76154bf5377e2202370f232e63a/mojo/public/tools/fuzzers/fuzz_impl.h
[modify] https://crrev.com/f6303bc9704fb76154bf5377e2202370f232e63a/mojo/public/tools/fuzzers/message_corpus/message_0.mojomsg
[modify] https://crrev.com/f6303bc9704fb76154bf5377e2202370f232e63a/mojo/public/tools/fuzzers/message_corpus/message_1.mojomsg
[add] https://crrev.com/f6303bc9704fb76154bf5377e2202370f232e63a/mojo/public/tools/fuzzers/message_corpus/message_10.mojomsg
[add] https://crrev.com/f6303bc9704fb76154bf5377e2202370f232e63a/mojo/public/tools/fuzzers/message_corpus/message_11.mojomsg
[modify] https://crrev.com/f6303bc9704fb76154bf5377e2202370f232e63a/mojo/public/tools/fuzzers/message_corpus/message_2.mojomsg
[add] https://crrev.com/f6303bc9704fb76154bf5377e2202370f232e63a/mojo/public/tools/fuzzers/message_corpus/message_9.mojomsg
[modify] https://crrev.com/f6303bc9704fb76154bf5377e2202370f232e63a/mojo/public/tools/fuzzers/mojo_fuzzer_message_dump.cc
[modify] https://crrev.com/f6303bc9704fb76154bf5377e2202370f232e63a/mojo/public/tools/fuzzers/mojo_parse_message_fuzzer.cc

Labels: Pri-3
NextAction: 2019-07-09
Downgrading P2s that haven't been modified in more than 6 months, which have no component or owner.

Sign in to add a comment