Executors and observers for non-native targets

[addisoncrump]

Is your feature request related to a problem? Please describe.
Currently, libafl only supports native targets. There are many targets which are not native, e.g. JavaScript, Python, Java, etc. targets, which can benefit from many of the existing observers, feedbacks, and other features present in libafl. Additionally, such support would allow us to unify efforts for different fuzzing domains.

Describe the solution you'd like
Executors and observers for various interpreted languages, e.g., libafl_v8, libafl_openjdk, libafl_pyo3, etc.

Describe alternatives you've considered
There are many existing fuzzers for interpreted/VM targets.

• JavaScript has jsfuzz and more recently jazzer.js
• Java has javafuzz and jazzer
• Python has pythonfuzz and atheris

Again, while these alternatives are present, it doesn't allow us the same extensibility or code reuse as libafl.

Additional context
In future work, we may be able to leverage such tools in greater contexts, e.g. libafl_v8 to find XSS bugs in various frontend JS libraries by integrating with Google Chrome and using something similar to the recent ExecSan work.

[addisoncrump]

Oh, and obviously I'm interested in working on this. :) I wanted to see what the libafl team's response would be before getting started. I'll make individual issues with tasks for each interpreted executor/observer.

[domenukk]

You can also take a look at libafl_atheris which can fuzz python:
https://github.com/AFLplusplus/LibAFL/tree/main/fuzzers/libafl_atheris

[domenukk]

(but obviously it's awesome if you want to work on this ;) )

[addisoncrump]

You can also take a look at libafl_atheris which can fuzz python: https://github.com/AFLplusplus/LibAFL/tree/main/fuzzers/libafl_atheris

Oops! I didn't grok that that was already present, despite looking at it multiple times 🤦 Getting it as its own executor would still be nice. :)

[domenukk]

We got some more executors now, like #864 #966 and #744 so closing for now