Merge "common_sense_risks.md" into "fuzzing_in_depth.md"

This commit is contained in:
llzmb 2021-11-24 10:52:29 +01:00
parent c866e9c3cc
commit f11cf068dc
3 changed files with 39 additions and 38 deletions

View File

@ -60,8 +60,8 @@ To build AFL++ yourself, continue at [docs/INSTALL.md](docs/INSTALL.md).
## Quick start: Fuzzing with AFL++ ## Quick start: Fuzzing with AFL++
*NOTE: Before you start, please read about the [common sense risks of *NOTE: Before you start, please read about the
fuzzing](docs/common_sense_risks.md).* [common sense risks of fuzzing](docs/fuzzing_in_depth.md#0-common-sense-risks).*
This is a quick start for fuzzing targets with the source code available. To This is a quick start for fuzzing targets with the source code available. To
read about the process in detail, see read about the process in detail, see

View File

@ -1,36 +0,0 @@
# Common sense risks
Please keep in mind that, similarly to many other computationally-intensive
tasks, fuzzing may put a strain on your hardware and on the OS. In particular:
- Your CPU will run hot and will need adequate cooling. In most cases, if
cooling is insufficient or stops working properly, CPU speeds will be
automatically throttled. That said, especially when fuzzing on less
suitable hardware (laptops, smartphones, etc), it's not entirely impossible
for something to blow up.
- Targeted programs may end up erratically grabbing gigabytes of memory or
filling up disk space with junk files. AFL++ tries to enforce basic memory
limits, but can't prevent each and every possible mishap. The bottom line
is that you shouldn't be fuzzing on systems where the prospect of data loss
is not an acceptable risk.
- Fuzzing involves billions of reads and writes to the filesystem. On modern
systems, this will be usually heavily cached, resulting in fairly modest
"physical" I/O - but there are many factors that may alter this equation.
It is your responsibility to monitor for potential trouble; with very heavy
I/O, the lifespan of many HDDs and SSDs may be reduced.
A good way to monitor disk I/O on Linux is the 'iostat' command:
```shell
$ iostat -d 3 -x -k [...optional disk ID...]
```
Using the `AFL_TMPDIR` environment variable and a RAM-disk you can have the
heavy writing done in RAM to prevent the aforementioned wear and tear. For
example the following line will run a Docker container with all this preset:
```shell
# docker run -ti --mount type=tmpfs,destination=/ramdisk -e AFL_TMPDIR=/ramdisk aflplusplus/aflplusplus
```

View File

@ -13,6 +13,43 @@ Fuzzing source code is a three-step process:
3. Perform the fuzzing of the target by randomly mutating input and assessing if 3. Perform the fuzzing of the target by randomly mutating input and assessing if
a generated input was processed in a new path in the target binary. a generated input was processed in a new path in the target binary.
### 0. Common sense risks
Please keep in mind that, similarly to many other computationally-intensive
tasks, fuzzing may put a strain on your hardware and on the OS. In particular:
- Your CPU will run hot and will need adequate cooling. In most cases, if
cooling is insufficient or stops working properly, CPU speeds will be
automatically throttled. That said, especially when fuzzing on less suitable
hardware (laptops, smartphones, etc.), it's not entirely impossible for
something to blow up.
- Targeted programs may end up erratically grabbing gigabytes of memory or
filling up disk space with junk files. AFL++ tries to enforce basic memory
limits, but can't prevent each and every possible mishap. The bottom line is
that you shouldn't be fuzzing on systems where the prospect of data loss is
not an acceptable risk.
- Fuzzing involves billions of reads and writes to the filesystem. On modern
systems, this will be usually heavily cached, resulting in fairly modest
"physical" I/O - but there are many factors that may alter this equation. It
is your responsibility to monitor for potential trouble; with very heavy I/O,
the lifespan of many HDDs and SSDs may be reduced.
A good way to monitor disk I/O on Linux is the `iostat` command:
```shell
$ iostat -d 3 -x -k [...optional disk ID...]
```
Using the `AFL_TMPDIR` environment variable and a RAM-disk, you can have the
heavy writing done in RAM to prevent the aforementioned wear and tear. For
example, the following line will run a Docker container with all this preset:
```shell
# docker run -ti --mount type=tmpfs,destination=/ramdisk -e AFL_TMPDIR=/ramdisk aflplusplus/aflplusplus
```
### 1. Instrumenting the target ### 1. Instrumenting the target
#### a) Selecting the best AFL++ compiler for instrumenting the target #### a) Selecting the best AFL++ compiler for instrumenting the target