afl++ addition

[vanhauser-thc]

Summary of the Pull Request

Adding afl++ as a default fuzzer, see #3

Info on Pull Request

adding afl++, basically just copying afl.* files to aflpp.* and making a few changes plus updating documentation

Validation Steps Performed

I am unsure if this is all that is needed. if so, sweet :)

[bmc-msft]

Thanks for the contribution! With a few adjustments, this would be a beneficial contribution:

1. The additional build script you added, src/ci/aflpp.sh, needs to be added to .github/workflows/ci.yml to execute.
2. We pin all redistributed third-party tools needs to specific revisions. As AFL++ does regular releases, can you update to use a specific release, such as https://github.com/AFLplusplus/AFLplusplus/archive/2.68c.tar.gz?

Rather than adding another CLI subcommand to launch afl++, it would be useful to expose another command line argument to the existing 'afl' subcommand that allows the user to specify which AFL binary to execute. The auto-generation of CLI using python typing will need an update to support this easily. I'm happy to do that part for you.

[bmc-msft]

Looking into the AFL template, we already allow the user to specify alternate implementations using 'fuzzer_setup_container', though it would be useful to enable providing a list of existing containers as possible options.

onefuzz template afl basic myproj target build-1 linux --fuzzer_setup_container aflpp-linux

[vanhauser-thc]

1. is done.
2. we have a stable branch which is always the newest afl++ with current additions, to which we push every 2-4 weeks. currently it is 2.68c. This would prevent needing to push a new version every 1-2 months. (the checkout in this PR is to the stable branch). Would that be fine?
3. this is a difficult question. afl and then sub commands for specific spin-offs or the specific spin-offs at the root command. IMHO It depends how compatible they are. e.g. afl++ has command line options that vanilla afl does not understand, also some environment variables. what do you think?

[bmc-msft]

1. I saw the update. Thanks! The llvm_mode does not compile. Based on the output, I think the github build VMs does not include the llvm-config prerequisite. In the short term, I think adding apt-get install llvm-config or apt-get install llvm will address this issue.

2. Keeping third-party versions up-to-date is a requirement of the Onefuzz team. We are required to keep track of the version and license of every component that gets integrated.

3. The need for researchers to specify custom arguments & environment variables is entirely reasonable and supported. I don't think we will want to try to keep up with fuzzing researcher's novel arguments & environment variables. Rather, our goal is to make it easy to specify anything custom, while providing basic sensible defaults as needed.

   In the afl commandline plugin, we provide a basic set of arguments to pass to afl-fuzz via --supervisor_options. By default for AFL, these are -d -i {input_corpus} -o {runtime_dir} -- {target_exe} {target_options}, where the onefuzz-agent replaces the '{str}' at runtime. Users can similarly specify environment variables via --supervisor_env KEY=VALUE KEY2=VALUE2.

[ranweiler]

This class isn't used or exposed anywhere yet. FYI, to actually expose it as a subcommand of template, it would need to instantiated and bound to self in .template.Template.__init__().

[ranweiler]

Also, we'd probably want to name this something like AFLPlusPlus to prevent ambiguity in the existing use site linked above.

[ranweiler]

To note another option here: we could add a plusplus (sub-)subcommand to the existing AFL template. This would just mean adding a plusplus method to the existing .afl.AFL class.

Exposing AFL++ as a method is compatible with arbitrary API differences between AFL and AFL++. It does not require any actual tool similarity. Sharing the afl part really just provides namespacing, and if desired, a convenient way to share setup code between templates (via the AFL class).

With that approach, invoking would look like:

onefuzz template afl plusplus <...>

[vanhauser-thc]

I renamed the class, pinned the checkout to v2.68c and installed the llvm components.

If there is any python stuff to do ... I can't do that. I can do C, C++, Assembly, even Perl ... but I stayed away from Python and anything beyond simple script changes is not something I feel comfortable to do :)

[bmc-msft]

I renamed the class, pinned the checkout to v2.68c and installed the llvm components.

Can you prefix the 'apt' calls with sudo?

If there is any python stuff to do ... I can't do that. I can do C, C++, Assembly, even Perl ... but I stayed away from Python and anything beyond simple script changes is not something I feel comfortable to do :)

That's fine. Can you delete the python code? I'll take on exposing afl++ via CLI in a meaningful fashion.

[vanhauser-thc]

sure! done.