hAFL2

hAFL2 is a kAFL-based hypervisor fuzzer.

It is the first open-source fuzzer which is able to target hypervisors natively (including Hyper-V), as it's support nested virtualization, code coverage and detailed crash monitoring.

Disclaimer

  1. I only had 3 weeks in order to implement this project from 0 as I worked at the same time on the hAFL1 project & Black Hat USA 2021 talk,
    therefore, I worked in a PoC mode (a.k.a. quick and dirty.) If I had the time, I'd definetly add more features and re-write some of the code, but I decided to release it anyway as it worked end-to-end, and I wanted to provide the infosec community a native hypervisor fuzzer because I didn't find a public one. I believe that it can help other researchers to learn the field of hypervisors internals and start their own hypervisor fuzzer.

  2. I personally used it in order to target the Hyper-V networking VSP (VMSwitch), which means that I retreived code coverage out of the root partition VM (L2), and sent fuzzing inputs directly to the child partition VM (L2) where my harness was executed.
    This behavior can be easily modified (e.g. retreiving code coverage out of the hypervisor itself on L1, etc.) and I explained exactly what needs to be done in order to make it work within the TechnicalDetails.md file.

VMSwitch Harness Gaps

Due to a lack of time, I have provided a partial harness for Hyper-V's VMSwitch which provide one the ability to send RNDIS packets from the guest partition to the root partition.

It's imporant to mention that there is a major gap in the harness - it won't provide you an accurate code coverage and I'll try to explain why.

The harness is responsible for the following:

  • Signal (ACQUIRE) hAFL2 to start collecting code coverage from the root partition.
  • Send the fuzzing payload to VMSwitch within the root partition.
  • Wait for a VMBus completion packet.
  • Signal (RELEASE) hAFL2 to stop collecting code coverage.

The problem is that VMSwitch processes packets in an asynchronous manner which means that it will call the interesting parsing code (which we'd like to have within our code coverage) AFTER it already sent a completion packet to the child partition's harness, therefore, the code coverage will be partial.

@OphirHarpaz and I solved a similar problem within hAFL1 by disabling PatchGuard and modifying some VMSwitch logic.
I believe this can be solved in a similar manner, maybe by patching VMSwitch and modifying the call to VmbChannelPacketComplete to occur after VMSwitch has finished the processing part.

Check out the Harness driver of hAFL1 in order to understand how we patched VMSwitch.

GitHub

https://github.com/SafeBreach-Labs/hAFL2