Skip to content

Commit

Permalink
Merge pull request #257 from IntelLabs/docs/fixes_dvkm
Browse files Browse the repository at this point in the history
dvkm: fixes
  • Loading branch information
Wenzel authored Oct 31, 2023
2 parents 245db56 + 33e37c2 commit 1f5373e
Show file tree
Hide file tree
Showing 3 changed files with 12 additions and 19 deletions.
19 changes: 8 additions & 11 deletions docs/source/tutorials/linux/dvkm/results.md
Original file line number Diff line number Diff line change
Expand Up @@ -222,7 +222,7 @@ The `kafl debug` subcommand provides various utilities for debugging your fuzzin

By using this subcommand, you can replay payloads to better understand the control flow leading to a crash, verify the stability and determinism of a payload, and even debug the guest state live while replaying the payload.

In this section, we'll explore two key [`actions`](../../../reference/fuzzer_configuration.md#action) provided by the kafl debug subcommand:
In this section, we'll explore two key [`actions`](../../../reference/fuzzer_configuration.md#action) provided by `kafl debug`:

- `single`
- `gdb`
Expand All @@ -234,9 +234,7 @@ The `single` action let's you replay a single payload and observe its results:
The payload should be specified throught the [`--input`](../../../reference/fuzzer_configuration.md#input) parameter.

:::{Important}
We should always specify [`--resume`](../../../reference/fuzzer_configuration.md#resume) when using either `kafl cov` or `kafl debug`, since it will replay from the original snapshot taken by the first call on [`NEXT_PAYLAOD`](../../../reference/hypercall_api.md#next_payload), and will make our execution deterministic.

That's one of the key benefits of snapshot fuzzers !
When replaying a payload from an previous kAFL run at $KAFL_WORKDIR, it is recommended to use [`--resume`](../../../reference/fuzzer_configuration.md#resume) so that the tool will use the exact same snapshot and page cache as in the fuzzing run. This improves our odds at reproducing the crash. If the workdir does not exist anymore or the snapshot is not found, running kafl single without `--resume` will simply boot a new VM with the given configuration and execute the agent a single time with the given input.
:::

:::{code-block} shell
Expand Down Expand Up @@ -396,7 +394,7 @@ For example when the target code will be fixed, we could replay that payload and

The `gdb` action is particularly valuable for deep-diving into the issues discovered during fuzzing.

When using this action, QEMU is started in `gdbserver` mode, which allows it to act as a server for the GDB debugger. This means you can interact with the target application in real-time as the payload is being executed.
This action working similar to `single`, but QEMU is started in `gdbserver` mode, allowing it to act as a server for the GDB debugger. This means you can interact with the target application in real-time as the payload is being executed.

The use of GDB provides fine-grained control over the execution of the program and allows you to inspect the program's state, variables, and call stack, offering a clear view into what led to a particular crash or unexpected behavior.

Expand Down Expand Up @@ -580,16 +578,15 @@ Breakpoint 2, oops_enter () at kernel/panic.c:623

:::{Important}
We need to use GDB hardware breakpoints, as software breakpoints in QEMU's embedded GDB server seems unrealiable.

::::{Note}
:::
:::{Note}
To reach the `dvkm_ioctl` hardware breakpoint, we had to send a `CTRL-C` to the GDB client.
The execution was hanging somewhere, for reasons that are not clear at the time of this writing.
::::
::::{Note}
Also remember that in order to load the symbols reliably, at the same location, we had to disable the Kernel `ASLR`.
:::
:::{Note}
Additionaly, in order to load the symbols reliably, at the same location, Kernel `ASLR` (_Address Space Layout Randomization_) had to be disabled.

Have a look at the `kafl.yaml` `qemu_append` line, where [`nokaslr`](https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html) option is set.
::::
:::

Hopefully by now, you should have a better understanding of the kAFL workdir's corpus directory, the captured logs and how to interpret them, as well as having the capacity to replay payloads as you will !
Expand Down
2 changes: 1 addition & 1 deletion docs/source/tutorials/linux/dvkm/target.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

## Objectives

The aim is to fuzz the [DVKM (Damned Vulnerable Kernel Module)](https://github.com/hardik05/Damn_Vulnerable_Kernel_Module), an example kernel module developed by[Hardik Shah](https://github.com/hardik05).
The aim is to fuzz the [DVKM (Damned Vulnerable Kernel Module)](https://github.com/hardik05/Damn_Vulnerable_Kernel_Module), an example kernel module developed by [Hardik Shah](https://github.com/hardik05).

Designed for fuzzing training, DVKM contains deliberately vulnerable code that exposes to a range of security vulnerabilities, including:
- integer overflow / underflow
Expand Down
10 changes: 3 additions & 7 deletions docs/source/tutorials/linux/dvkm/workflow.md
Original file line number Diff line number Diff line change
Expand Up @@ -59,16 +59,14 @@ Additionally, you must set up a communication channel with the VM. Several optio
- [Ansible playbook](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_intro.html)

:::{note}
If you want to have a look at this kind of workflow, the [Windows driver](../../windows/driver/index.md) target is a good example.

It combines [Packer](https://www.packer.io/), [Vagrant](https://www.vagrantup.com/), and [Ansible](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_intro.html) with [WinRM](https://learn.microsoft.com/en-us/windows/win32/winrm/portal) channel to provide a convenient setup.
The [Windows driver](../../windows/driver/index.md) example target demonstrates how to combine [Packer](https://www.packer.io/), [Vagrant](https://www.vagrantup.com/), and [Ansible](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_intro.html) with [WinRM](https://learn.microsoft.com/en-us/windows/win32/winrm/portal) channel to provide a convenient setup.
:::

### Direct Kernel Boot and initrd

For targets that are kernel-based, such as ours, a more efficient approach is to use QEMU's [Direct Linux Boot](https://qemu-project.gitlab.io/qemu/system/linuxboot.html) feature in tandem with a custom initrd.
Open source kernel and firmware targets can often be booted using QEMU's [Direct Linux Boot](https://qemu-project.gitlab.io/qemu/system/linuxboot.html) feature.

This configuration forms a lightweight execution environment that can bypass the need for a full OS image.
This approach is often more efficient than bootng a full-VM image and easier to customize and script.

```{code-block} shell
---
Expand All @@ -77,8 +75,6 @@ caption: Example using `qemu_kernel` (`--kernel`) and `qemu_initrd` (`--initrd`)
(venv) $ kafl fuzz --kernel /path/to/linux/arch/x86/boot/bzImage --initrd /path/to/initrd.cpio.gz
```

Below, we outline how to construct an efficient development workflow leveraging this approach.

## Initrd and `agent.sh` workflow

The approach outlined here relies on crafting a custom initrd that boots into a minimal BusyBox root filesystem.
Expand Down

0 comments on commit 1f5373e

Please sign in to comment.