Nautilus: a grammar based feedback fuzzer

 

https://github.com/RUB-SysSec/nautilus

https://www.ndss-symposium.org/ndss-paper/nautilus-fishing-for-deep-bugs-with-grammars/

3 new research papers on fuzzing

 

https://arxiv.org/abs/1901.01142

https://arxiv.org/abs/1812.01197

https://arxiv.org/abs/1812.00140

 

Drill Apple Core: Up and Down – Fuzz Apple Core Component in Kernel and User Mode for Fun and Profit

https://www.blackhat.com/eu-18/briefings/schedule/index.html#drill-apple-core-up-and-down—fuzz-apple-core-component-in-kernel-and-user-mode-for-fun-and-profit-12923

http://i.blackhat.com/eu-18/Wed-Dec-5/eu-18-Wu-Drill-Apple-Core.pdf

Google on fuzzing PCIe

https://twitter.com/revskills/status/830102871077224448

Fuzzing PCI express: security in plaintext
By Julia Hansbrough, Software Engineer

Google recently launched GPUs on Google Cloud Platform (GCP), which will allow customers to leverage this hardware for highly parallel workloads. These GPUs are connected to our cloud machines via a variety of PCIe switches, and that required us to have a deep understanding of PCIe security. Securing PCIe devices requires overcoming some inherent challenges. For instance, GPUs have become far more complex in the past few decades, opening up new avenues for attack. Since GPUs are designed to directly access system memory, and since hardware has historically been considered trusted, it’s difficult to ensure all the settings to keep it contained are set accurately, and difficult to ensure whether such settings even work. And since GPU manufacturers don’t make the source code or binaries available for the GPU’s main processes, we can’t examine those to gain more confidence. You can read more about the challenges presented by the PCI and PCIe specs here. With the risk of malicious behavior from compromised PCIe devices, Google needed to have a plan for combating these types of attacks, especially in a world of cloud services and publicly available virtual machines. Our approach has been to focus on mitigation: ensuring that compromised PCIe devices can’t jeopardize the security of the rest of the computer. Fuzzing to the rescue[…]

https://cloudplatform.googleblog.com/2017/02/fuzzing-PCI-Express-security-in-plaintext.html

Dodgy Coder on modern fuzzers

Dodgy Coder posted a new blog post on fuzzing.

Summer @ Trail of Bits

Not specifically firmware-centric, but firmware could use a lot more fuzzing. If you haven’t looked at KLEE+S2E+Avatar+QEMU, check it out! 🙂 Intel is apparently using fuzzing to help test UEFI’s SMM:

https://firmwaresecurity.com/2015/08/10/intel-firmware-security-research-at-woot/

fuzzing tool: afl

Hanno Böck has an article on LWN.net on the fuzzing tool afl, American Fuzzy Lop, created by Michał Zalewski of the Google security team:

AFL is a powerful fuzzer, and the above article is a good introduction. There are some more extensive tutorials on afl site, as well as the Fuzzing Project site. Hanno created the Fuzzing Project, which uses FOSS fuzzers to find and fix defects in core FOSS projects. Besides afl, there’s a Python attempt at a version, for those that prefer Python.

http://lcamtuf.coredump.cx/afl/
http://jwilk.net/software/python-afl
https://fuzzing-project.org/tutorials.html

(I wish there was more widespread usage of AFL in coreboot, tianocore, U-Boot, SeaBIOS, especially now that SMM is inside OVMF now…)