Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/google/buzzer
https://github.com/google/buzzer
Last synced: 3 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/google/buzzer
- Owner: google
- License: apache-2.0
- Created: 2023-03-21T13:22:02.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2024-07-26T17:20:45.000Z (3 months ago)
- Last Synced: 2024-07-26T19:06:00.277Z (3 months ago)
- Language: Go
- Size: 773 KB
- Stars: 364
- Watchers: 11
- Forks: 29
- Open Issues: 9
-
Metadata Files:
- Readme: README.md
- Contributing: CONTRIBUTING.md
- License: LICENSE
Awesome Lists containing this project
- my-awesome - google/buzzer - 08 star:0.4k fork:0.0k (Go)
README
# Buzzer - An eBPF Fuzzer toolchain
![ci_status](https://github.com/google/buzzer/actions/workflows/ci.yml/badge.svg)
Buzzer is a fuzzer toolchain that allows to write eBPF _fuzzing strategies_.
A Fuzzing strategy is a way to generate random eBPF Programs and then validate
that they don't have unexpected behaviour.To run the fuzzer follow the next steps
1. Install [bazel](https://bazel.build/).
1. Install [clang](https://clang.llvm.org/)
1. Setup the correct CC and CXX env variables
```
export CC=clang
export CXX=clang++
```
1. Run
```
bazel build :buzzer
```
1. Run buzzer either as root:
```
sudo ./bazel-bin/buzzer_/buzzer
```
OR with CAP_BPF:```
sudo setcap CAP_BPF=eip bazel-bin/buzzer_/buzzer
./bazel-bin/buzzer_/buzzer
```
## Documents:* [Overall Architecture of Buzzer](docs/architecture/architecture.md)
* [How to run buzzer with coverage](docs/guides/running_with_coverage.md)## Trophies
Did you find a cool bug using _Buzzer_? Let us know via a pull request!
We'd like to collect all issues discovered with this framework under this
section.* [CVE-2023-2163](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71b547f561247897a0a14f3082730156c0533fed):
An error in the branch pruning logic of the eBPF verifier can cause unsafe
paths to not be explored. The unsafe pruned paths are the actual paths taken
at runtime which causes a mismatch in what the verifier thinks the values of
certain registers are versus what they actually are. This mismatch can be
abused to read/write arbitrary memory in the kernel by using the confused
registers as base registers for memory operations.* [CVE-2024-41003](https://github.com/google/security-research/security/advisories/GHSA-hfqc-63c7-rj9f):
A bug in the verifier's register limit tracking allows an attacker to trick
the verifier into thinking a register holds a value of 0 when at run time
this register could take a value of 1. This can be then leveraged to achieve
arbitrary kernel memory read/write and lead to a local privilege escalation
or container escape.